Abstract

Traditional microsegmentation relies on VLAN tags, ACLs, and firewall rules applied at the network perimeter or at the hypervisor vSwitch layer. This model creates operational burden when workloads are ephemeral and identities change faster than VLAN assignments can be updated. Cilium, a CNI plugin for Kubernetes built on eBPF, approaches microsegmentation differently: it attaches BPF programs directly to the kernel’s networking hooks and enforces identity-based policy without requiring network topology changes or VLAN provisioning. This article covers how Cilium assigns workload identities, how eBPF programs enforce policy at the socket and TC layers, and what the operational model looks like for teams running it in production.

Identity Without VLAN Tags

Cilium assigns a numeric security identity to every endpoint based on its Kubernetes labels. The identity is derived by hashing the label set and distributed to all nodes via a key-value store (etcd or the Kubernetes CRD-based identity store). When a pod is scheduled, the Cilium agent on that node computes its identity, writes a local identity mapping, and attaches BPF programs to the pod’s veth pair.

Packets leaving an endpoint carry the identity in the packet’s route metadata (via Linux’s skb->mark or a custom encapsulation header when running in VXLAN or Geneve overlay mode). When a packet arrives at the destination node, the receiving BPF program looks up the source identity and evaluates the applicable NetworkPolicy. Policy is compiled to BPF map lookups - there is no userspace component in the packet path. The entire allow/deny decision happens in kernel context in a few hundred nanoseconds per packet.

This is the key distinction from VLAN-based approaches. Network topology does not need to change when a workload’s policy changes; only the BPF map entries are updated, and that update propagates across nodes in milliseconds via the Cilium operator and agent.

Policy Enforcement at TC and Socket Layers

Cilium attaches BPF programs at two kernel hooks: the Traffic Control (TC) ingress/egress hooks on veth interfaces and, for local socket-to-socket traffic on the same node, the socket-level hooks via BPF_PROG_TYPE_SOCK_OPS and BPF_CGROUP_SOCK_ADDR programs. The socket-level enforcement short-circuits the kernel network stack for local traffic - a packet between two pods on the same node never reaches the TC layer; it is evaluated and redirected at the socket before any IP routing occurs.

Kubernetes NetworkPolicy objects are translated to Cilium’s own policy representation and then compiled into BPF map entries by the Cilium agent. CiliumNetworkPolicy CRDs extend the standard Kubernetes API to support L7 policies - HTTP path matching, DNS-based egress rules, and Kafka topic-level policies - which standard NetworkPolicy cannot express. L7 enforcement proxies the matching traffic through Envoy (embedded in the Cilium agent process) after the L3/L4 BPF allow check passes.

Node-to-Node Encryption

Cilium supports WireGuard-based transparent encryption between nodes in a cluster, controlled by the --enable-wireguard flag. When enabled, the Cilium agent establishes a WireGuard tunnel to every other node and routes inter-node pod traffic through it automatically. From the application’s perspective, the connection is unencrypted; encryption happens at the node boundary without requiring TLS certificates in each pod or a service mesh sidecar. Compared to IPsec mode (which Cilium also supports), WireGuard has lower CPU overhead and simpler key rotation because WireGuard manages key exchange natively.

This matters for microsegmentation deployments that span availability zones or bare-metal racks without physical layer encryption. Encrypting the overlay with WireGuard ensures that lateral movement between compromised workloads is not aided by plaintext packet capture on the underlay.

Operational Considerations

The Hubble observability layer, built into Cilium, is the practical tool for validating that policy is working correctly. Hubble exposes a flow log of all allowed and denied connections with source and destination identities, L3-L7 metadata, and timestamps. The hubble observe CLI and Hubble UI provide real-time visibility without requiring a separate network tap or packet capture infrastructure. Teams transitioning from VLAN-based segmentation typically spend the first weeks in policy audit mode - running Cilium with all traffic allowed but Hubble logging enabled - to build an accurate picture of actual communication patterns before writing deny rules.

BPF map sizing is the operational parameter teams most commonly misconfigure. Each node has a bounded number of BPF map entries for policy and identity lookups. In clusters with high identity churn (short-lived batch jobs with unique label sets), the identity GC cycle and map update frequency can become a source of latency spikes. Cilium’s identity allocator has configurable limits and GC intervals that should be tuned based on the workload profile of the cluster.