Not all CNIs are created equal, and many assume that CiliumNetworkPolicies are the same as standard Kubernetes NetworkPolicies. At first glance, they can look similar. You define selectors, specify ingress or egress rules, and control which workloads can talk to each other. But once you look a little closer, it becomes clear that Cilium is operating at a very different level. Built on eBPF, Cilium moves policy enforcement into the kernel and attaches identity directly to workloads, unlocking capabilities that go well beyond what traditional CNIs were designed to handle. For NetOps Engineers, this is where things get interesting. If you are comfortable with subnets, ACLs, and basic L3/L4 filtering, Cilium expands that model into identity aware, application-aware, and even DNS aware controls. It is not just about allowing traffic between IPs anymore. It is about defining intent based on service accounts, enforcing policies cluster-wide, filtering traffic by domain names, inspecting HTTP requests at Layer 7, and getting deep observability without bolting on a separate tool. In this blog, we will walk through five things you may not realize Cilium Network Policies can do that set them apart from standard Kubernetes networking. Identity Based Model Before we jump into hands-on policy examples, let’s first walk through the security model that makes Cilium different from traditional IP based enforcement. Kubernetes gives every Pod its own IP address. That model is simple and avoids NAT, but it also means a busy cluster can have a very large and constantly changing set of IP addresses. Enforcing security the traditional way with IP based rules, you can run into scale problems. For example, allowing role=frontend Pods to talk to role=backend Pods means every node hosting a backend Pod must maintain a list of all frontend Pod IPs. Every time a Pod is created or deleted, those IP based rules must be updated across the cluster. In high churn environments, that can mean frequent rule updates and even delays while policies converge within the cluster. Cilium takes a different approach by separating security from IP addresses and tying it to identity derived from Kubernetes labels. Each set of labels maps to a numeric security identity, and policies are enforced based on those identities instead of individual IPs. When a new role=frontend Pod starts, it reuses the existing identity associated with that label set. Backend nodes do not need their rules rewritten for every new frontend IP. Only the identity needs to be resolved, which reduces rule churn and improves scalability while keeping policy aligned with Kubernetes semantics. You can see this being more powerful when you take into consideration that Cilium can inject a Layer 4 proxy into any network connection, transparently. This is used as the foundation to enforce higher level network policies and enable other L7 capabilities via Envoy. With that in mind, let’s go over some example Cilium Network Policies that extend the standard Kubernetes Networking Policies. Cluster Wide CiliumNetworkPolcies Using Cilium as a CNI gives you the ability to do cluster level policies. At a glance, the key difference between CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy comes down to scope. CiliumNetworkPolicy is namespace scoped and is usually managed by application teams to control traffic for their own workloads. CiliumClusterwideNetworkPolicy applies across the entire cluster and is evaluated no matter which namespace a workload lives in. This cluster wide policy concept does not exist in standard Kubernetes NetworkPolicy, where every rule must be defined and maintained at the namespace level. A good use of a CiliumClusterwideNetworkPolicy, is to prevent any Pod from accessing the cloud metadata service, which is a frequent target in container breakouts. Once applied, all Pods are denied egress to the cloud metadata service, working as a global guardrail for the entire cluster. These cluster-level policies shine when you need consistent, platform level barriers that should be applied for any workload in your setup. As you saw in the example, It is well suited for things like blocking access to cloud metadata endpoints, but can be used for enforcing egress restrictions, protecting core infrastructure services, or setting a default zero trust posture across the cluster. Because these policies are defined once and enforced globally, they reduce duplication and configuration drift, especially in multi-tenant environments. For platform and security teams, this fills an important gap left by standard Kubernetes NetworkPolicies and provides a much cleaner way to express and enforce global networking policies. CiliumNetworkPolicies by ServiceAccount Cilium’s support for ServiceAccount based network policies brings a more human idea of identity into Kubernetes networking. Instead of trusting pod labels or chasing changing IPs, policies can be written around which ServiceAccount a workload runs as. This makes it a much approachable way to apply zero-trust principles inside the cluster, where only explicitly trusted workloads can reach sensitive services. Since ServiceAccounts tend to be stable and already tied to RBAC, these policies are not only stronger from a security perspective but also simpler to reason about and maintain. To see this in action, I have a sample pod webapp, deployed to my Kubernetes cluster: This webapp can be accessed by other workloads in the namespace: However, I may not want all workloads within a namespace to access this webapp: I can mitigate this by only allowing workloads running as a specific serviceAccount to access my webapp, for example: Note, I’m only allowing workloads running as the serviceAccount named good to access workloads running as the serviceAccount named webapp-sa. With this applied, I ensure my workload is running as the serviceAccount that is allowed: I should still be able to access the webapp from this Pod: While the others are denied access via this CiliumNetworkPolicy: In practice, this approach shines in multi-tenant setups or platform environments or whenever a Kubernetes cluster is shared by different workloads. It helps cleanly separate workload traffic from controllers and infrastructure components, and it significantly reduces the risk of lateral movement if a pod is compromised. For NetworkOps teams, ServiceAccount aware policies feel familiar, closer to identity based access control than traditional IP rules, while fitting naturally into how Kubernetes already models trust. DNS based CiliumNetworkPolicies Cilium’s policy language supports things like DNS and FQDN based rules, explicit deny rules, and even L7 controls for HTTP methods. Unlike standard Kubernetes policies that only allow you to work with IPs, ports, and namespaces, Cilium lets you have finer grained control over policies. An important part of Cilium’s approach is its DNS policy that lets you write rules based on domain names instead of hard-coding IP addresses. For example, if I want to restrict a workload to only have access to a specific API endpoint by DNS name, I can apply the following policy: This will allow access to the DNS name of the service, even if the IP address is changed: The rule then goes on only allowing queries to the specified endpoints. All others are denied: Cilium does this by observing DNS responses and dynamically tracks the IPs associated with those names, applying policy based on the resolved addresses while respecting DNS TTLs and configured match patterns.This approach makes policies easier to read and maintain, especially when dealing with external services whose IPs change frequently. This makes Cilium network policies fit naturally into modern Kubernetes environments where services are dynamic, identities matter more than addresses, and networking needs to keep up with the pace of application change. Layer 7 CiliumNetworkPolicies Cilium allows you to enforce Layer 7 rules on top of the standard network controls, meaning you can filter traffic not just by IPs and ports, but by application level protocols like HTTP. With HTTP rules, you can specify which URLs, methods, or headers are allowed or denied between workloads. For example, you could allow traffic to a service only if it’s a GET request to a specific endpoint, while blocking all other requests. This will allow access to the /public endpoint: This goes beyond typical firewall-style controls, however, as you can see with the 403 error. This lets you set traffic based rules on actual application behavior, not just network topology. Under the hood, Cilium uses envoy to assist with inspection HTTP requests in real time. Policies can be applied at the pod or cluster level, and they combine seamlessly with identity-based endpoint selectors. This allows you to create fine-grained, zero-trust style controls for microservices. HTTP rules can also be combined with DNS or FQDN rules (shown above), so you can enforce that only certain services are reachable and only in the ways you explicitly allow. For NetOps engineers, who are accustomed to ACLs, this feels like adding context aware inspection to your network filters, making Kubernetes workloads much safer and more predictable. Observability is Built In One of the powerful advantages of running Cilium as your CNI is that you automatically get Hubble, which is our “batteries included” observability platform. There’s no separate agent to deploy, no sidecar to manage, and no additional setup required. Hubble is powered directly by Cilium’s eBPF datapath, which means observability is effectively “for free” as soon as Cilium is installed. It gives you deep visibility into network flows, DNS queries, HTTP requests, and even Layer 7 policy decisions, all without modifying your applications. Instead of guessing why traffic is being dropped or allowed, you can see the exact flow events in real time. Hubble also provides multiple ways to consume that visibility. The Hubble CLI feels very similar to tcpdump, letting you filter live traffic by namespace, pod, labels, protocols, or verdicts like DROPPED and FORWARDED. For instance, I can use the hubble CLI to see any traffic that has been DROPPED to a specific workload: Another great thing is the ability to see protocols such as DNS communication: This built-in feature is incredibly useful for debugging policies or understanding workload to workload communication in Kubernetes. On top of that, Hubble offers a rich UI that visually maps service interactions, making it easy to see dependencies and spot issues at a glance. It also has the ability to build CiliumNetworkPolcies in the UI as well! For teams adopting a zero trust model with Cilium, Hubble completes the story by showing not just what should happen according to policy, but what is actually happening in the cluster. Summary Cilium Network Policies are not just a drop-in replacement for standard Kubernetes NetworkPolicies, they are a superset. They extend the model in ways that better match how modern clusters operate. By shifting from IP-based thinking to identity, DNS awareness, application context, and built-in observability, Cilium gives platform and security teams stronger controls without adding operational complexity. For Kubernetes professionals with a networking background, this is a natural evolution. The fundamentals still apply, but the controls are more granular, more dynamic, and more aligned with zero trust principles. Want to see these in action? Check out the demo video below!