Isovalent Enterprise for Cilium 1.15 introduces a new feature to manage the behaviour of default deny applied to workloads when Cilium Network Policies are Implemented. This video walkthrough will show the operational risk of applying broad policies to existing workloads, and how to avoid accidental outages using this new feature. Introduction Today Cilium provides fantastic granular network policy control across your cloud-native platforms, beyond the scope and features that are available out of the box with Kubernetes Network Policies. It's actually one of the reasons why customers start using Cilium in their environments. They want more granular control at a security level, and then they discover other features such as Egress Gateway, the Hubble Enterprise UI, Hubble Timescape, and so on. In today's video I'm going to cover how you can control the default deny behavior of network policies in Isovalent Enterprise for Cilium 1.5. This feature will be available in the open source version of Cilium 1.16 in the future, but our engineering team at Isovalent has already backported that into an earlier version of our Enterprise offering for customers. So what is this feature about? If we consider a large Kubernetes cluster made up of lots of multi-tenant workloads, the owner of the platform may want to introduce new policies. Policy configuration Those new policies may proxy all DNS requests for monitoring purposes, deny access to sensitive IPs such as cloud metadata API addresses, or introduce new clusterwide tooling such as security scanners or data protection software. Network Policies already have all of the features needed in the policy language to implement those types of policies today. However, applying a broad type of policy to an existing platform does carry operational risk. These broader policies may be the first policy to apply to an endpoint inside of your cluster. If we consider an existing cluster state where we've deployed workloads but have no existing Network Policy, like my current demo app, we can see there are no policies applied. That means by default all traffic is allowed to and from those pods and in and out of that namespace as well. If we start to apply a broad policy into that environment, then anything that doesn't match that policy's rule set will be denied by default. Let's see that in action. Here I've got a clusterwide network policy, and I'm going to go through the use case of intercepting all DNS requests for observability reasons. default deny network policy observability We want to capture anything on TCP or UDP port 53 that matches DNS patterns as well. This is available in any version of Cilium you want to run today, whether that's Enterprise or open source. Before I do that, let's just find my Hubble observe command because I want to make sure all traffic is working with that tenant-jobs app, and as we can see all the traffic is forwarded. Now I'm going to apply that file into my terminal. If I run Hubble observe again, we can see new communications from those applications going externally are dropped, and traffic inside of the environment is also dropped. Any DNS requests are still forwarded because that's what we're proxying. You can see the denied egress. Everything else is dropped, which is obviously not what we want within the environment. So I'm going to delete that CiliumClusterwideNetworkPolicy and then double-check from the observe point of view that we've gone back to a working environment where everything is forwarded as we'd expect. That's really great, and now with this new feature in Isovalent Enterprise for Cilium 1.5, and later in open source 1.16, we have the ability to set the behavior of default deny. We can set inside that Cilium Network Policy, whether it's a namespace policy or a clusterwide policy, the ability to disable that default deny behavior. So even if this policy is the first policy applied to a workload, it will not affect that workload by denying traffic just because nothing else matches. Now let's observe the same behavior by applying that version of the policy. Once it's applied, if we do Hubble observe we can see that all of my traffic continues to be allowed inside of the environment because it is not denied by default when it doesn't match that broader rule. It's a really key feature because it allows you to mitigate operational risk when making broad changes in an existing Kubernetes platform with existing workloads as well. Thank you very much.