From Perimeter Security to Software-Defined Networking: Zero Trust and Observability with Cilium and eBPF

1. The evolution of security and networking

 

1.1. Software-defined networking in Kubernetes environments

The shift to cloud-native microservices architectures has made traditional perimeter security approaches obsolete. In legacy infrastructures, security relied mainly on L3/L4 firewalls physically placed at the network boundary. In a Kubernetes ecosystem, workloads are ephemeral, dynamic, and distributed: a pod can be created and destroyed within seconds, constantly changing its IP address. A static, IP-based approach therefore becomes inefficient and impossible to scale. Software-defined networking (SDN) overcomes this limit by decoupling the logical infrastructure from the physical one: the network becomes programmable, and micro-segmentation policies are tied to the pods' cryptographic identities (or labels), resulting in a far more resilient and inherently secure architecture.

 

1.2. eBPF overview and concepts

Next-generation SDN is built on eBPF (extended Berkeley Packet Filter). This technology runs highly optimized sandboxed programs directly in Linux kernel space, without modifying the kernel source code or loading additional modules. In networking, eBPF hooks into strategic interception points (such as XDP, eXpress Data Path, and TC, Traffic Control), bypassing the traditional and slower Linux network stack (such as iptables and netfilter). The result is packet filtering and routing with exceptional performance (often at hardware line rate) and minimal CPU overhead.

 

1.3. Cilium: Zero-Trust networking for cloud native

Cilium is the open source platform that harnesses eBPF to provide networking, security, and observability natively in Kubernetes. Replacing kube-proxy-based networking, Cilium integrates as a Container Network Interface (CNI) and can operate at every layer of the OSI model, up to Layer 7 (application). When advanced traffic inspection is required (e.g., HTTP, gRPC, or Kafka calls), Cilium transparently redirects packets from the eBPF datapath to an integrated Envoy proxy. This hybrid kernel/user-space model enables native Zero-Trust architectures, with encrypted pod-to-pod communication (mTLS) and granular security policies, without a significant performance impact.

 

2. Case study: transformation at a digital services provider

This case study examines the technology adoption path of a major customer that provides digital services to the public and private sectors. The goal was to modernize the network infrastructure of its Kubernetes clusters, overcoming the bottlenecks of traditional load balancers and gaining full visibility into application traffic.

2.1. Architecture and implementation: Gateway API and L2 announcements

As the new Kubernetes environments were set up, Cilium was introduced to replace the previous networking solutions, with a focus on two key architectural innovations. Let's look at them briefly.

• Gateway API adoption - The customer chose to move beyond classic Ingress controllers by adopting the newer Kubernetes Gateway API standard, which Cilium supports natively. Technically, this standard decouples the infrastructure definition (the Gateway, managed by administrators) from the routing rules (the HTTPRoute resources, managed by developers). Cilium translates these resources directly into eBPF and Envoy configurations and handles inbound (north-south) traffic more expressively, for example with advanced routing based on HTTP headers, paths, and weights for canary releases, all without deploying dedicated external proxies.

 

• L2 node balancing (L2 Announcements) - In on-premises environments, exposing services externally typically requires a software load balancer (such as MetalLB) or expensive hardware appliances. With Cilium, the customer used the native L2 Announcements feature. Technically, Cilium uses a leader election mechanism based on Kubernetes Leases to assign ownership of a virtual IP (VIP) to a specific node. The Cilium agent on that node answers ARP (IPv4) or NDP (IPv6) requests on the local network (Layer 2). If the node fails, a new leader is elected and sends gratuitous ARP messages to update the network switches. This provided highly available load balancing without adding components to the cluster, while remaining compatible with the existing external VMware load balancers running in parallel.

 

2.2 Network observability and an integrated next-generation firewall (L7)

The real turning point of the project was enabling Hubble, Cilium's native observability framework. Because eBPF “sees” every packet that crosses the kernel, Hubble collects this telemetry directly from eBPF ring buffers, giving the customer a real-time topology map of communications (Service Map), complete with metrics on latency, packet drops, and HTTP status codes.
This visibility made it possible to implement CiliumNetworkPolicies (CNPs) safely and in measured steps. While traditional firewalls and standard Kubernetes NetworkPolicies stop at L3/L4 (IP addresses and ports), CNPs also operate at application level (L7). The customer was able to implement restrictive rules based on external hostnames (FQDNs), for example allowing traffic only to api.github.com or vcenter.local. Technically, Cilium intercepts outgoing DNS queries from pods (DNS proxy), caches the IPs returned for that domain, and dynamically applies eBPF firewall rules only to those addresses, for the DNS time to live (TTL).

This capability turned the network infrastructure into a distributed next-generation firewall. The customer was able to remove the external HTTP proxies previously used to filter outbound traffic, cutting latency and eliminating a critical single point of failure (SPOF).

 

2.3 Roadmap: service mesh, Egress Gateway, and Tetragon

Building on this success, the customer's architecture roadmap points toward an even more scalable infrastructure.

• Cilium Cluster Mesh - Interconnecting multiple independent Kubernetes clusters. Pods in different clusters will be able to communicate directly (east-west) as if they were on the same network, with native mTLS encryption and consistent enforcement of security policies, without the bottlenecks of traditional VPN gateways.
• Cilium Egress Gateway - To integrate Kubernetes traffic with the data center's strict physical perimeter firewalls, the Egress Gateway will be implemented. This eBPF feature will masquerade outbound traffic from specific namespaces or pods, so that it leaves the cluster with static, predictable source IP addresses. External legacy firewalls will then be able to identify and filter traffic from the microservices reliably.
• Runtime security with Tetragon - Beyond networking, the customer will evaluate Tetragon, an eBPF agent that provides runtime security. Tetragon intercepts system calls (syscalls) directly in the kernel and can block anomalous process executions, privilege escalation attempts, or access to sensitive files in real time, completing the Zero-Trust posture end to end.