How Cilium Security Identities Work Instead of IP-Based Rules (2026)

Cilium security identities are a revolutionary way to manage network security, ditching brittle IP addresses for something far more robust and dynamic.

Let’s see this in action. Imagine you have two services, frontend and backend. Normally, you’d write a firewall rule like "allow traffic from IP 10.0.0.5 to 10.0.0.10 on port 8080." But what if backend scales up and gets a new IP? Your rule breaks.

With Cilium, you’d instead define a policy like this:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Here, frontend and backend are not IPs, but security identities. Cilium assigns a unique, numerical identity to each pod (or service, or host) based on its Kubernetes labels. When a frontend pod wants to talk to a backend pod, Cilium doesn’t look at source and destination IPs. It looks at the identities of the pods involved. If the identity of the source pod matches the app: frontend label in the policy, and the destination pod has the app: backend label and is listening on port 8080 TCP, the connection is allowed. If backend gets a new IP address because it scaled, its identity remains the same, and the policy continues to work without any changes.

This identity-based model is powered by eBPF, a technology that allows custom code to run safely within the Linux kernel. Cilium uses eBPF to intercept network packets at the earliest possible moment – right after they enter or before they leave the network interface. Instead of relying on traditional kernel networking stack rules (like iptables), Cilium programs eBPF logic directly into the kernel. This logic contains mappings from pod identities to their current IP addresses and enforces the security policies. When a packet arrives, the eBPF program checks the identity of the source and destination pods and, based on the pre-defined security policy, decides whether to allow or deny the packet. This is incredibly efficient because it bypasses much of the traditional kernel networking overhead.

The key to this is the Cilium Agent running on each node. This agent is responsible for:

1. Discovering Pods and Services: It watches the Kubernetes API for new pods, services, and their associated labels.
2. Assigning Identities: For each discovered entity, it assigns a unique, numerical security identity. This identity is persistent for the lifetime of the pod/service.
3. Generating eBPF Programs: Based on the security policies defined in Kubernetes (CiliumNetworkPolicy or NetworkPolicy), the agent generates and loads eBPF programs into the kernel. These programs contain the logic to enforce the policies using the assigned identities.
4. Maintaining State: It keeps a real-time mapping of which identity corresponds to which pod IP address on its node. When a pod’s IP changes (e.g., due to rescheduling or scaling), the agent updates its internal state and ensures the eBPF programs are aware of the new IP.

When a packet needs to be sent or received, the eBPF program attached to the network interface intercepts it. It looks up the originating and destination identities of the packet (often by inspecting pod metadata associated with the socket or by correlating with the IP address using tables maintained by the Cilium agent). It then consults its policy rules, which are also embedded within the eBPF program or accessible to it. If the policy permits the communication, the packet is allowed to proceed. Otherwise, it’s dropped. This happens entirely in the kernel, making it extremely fast.

One of the most powerful, yet often overlooked, aspects of Cilium’s identity system is its ability to handle L3/L4 policy enforcement for various protocols without needing to know the underlying network topology or IP addresses. For instance, you can create a policy that allows a database service to only be accessed by backend services on port 5432/TCP. Cilium’s eBPF programs, armed with the identities, perform this check. They don’t need to know if backend is on the same node as database, or if the traffic will traverse multiple network hops. The identity mapping and policy enforcement are handled locally by the eBPF code, abstracting away the complexities of network routing and IP management. This also means that as your cluster grows and IPs are dynamically assigned, your security policies remain stable and effective.

The next step after mastering security identities is understanding how Cilium leverages them for advanced features like service mesh capabilities and observability.