Cilium: eBPF-based Networking for Zero Trust and Compliance

TL;DR

• Cilium leverages eBPF to execute network functions directly in the Linux kernel, enabling high-performance, identity-based networking for modern Kubernetes platforms.
• For Zero Trust architectures, Cilium provides essential components: fine-grained Network Policies (microsegmentation), end-to-end encryption via WireGuard, deep observability with Hubble, and intrusion detection capabilities.
• eBPF combines performance, flexibility, and security: it extends the kernel in a controlled manner without the need for patching, creating a solid technical foundation for regulatory transparency and control over network traffic.
• Namespace isolation can be implemented with Cilium to ensure tenants are clearly separated, only explicitly allowed connections are possible, and all flows can be traced in a revision-secure manner—a direct lever for auditability and Compliance.
• ayedo uses Cilium as the standard network component in its own Kubernetes distribution, integrating it into logging, monitoring, and governance processes, and supporting organizations in pragmatically implementing Zero Trust and compliance requirements.

Why Network Security Becomes the Foundation of Compliance

Network communication is no longer “just” an infrastructure topic. It has become a central component for information security and thus for regulatory compliance.

With the NIS2 directive, which must be transposed into national law by 17.10.2024, stricter requirements for the security of critical and important facilities will become binding across Europe. DORA comes into effect on 17.01.2025 and explicitly addresses digital resilience in the financial sector. Both regulatory strands essentially demand the same: traceable, controllable, and verifiable control over data flows.

At the same time, more and more teams are working based on Kubernetes, microservices, and highly dynamic platforms. IPs, pods, and workloads are constantly changing there—classic, IP-based network security hardly scales under these conditions. What worked in static data centers quickly becomes a governance risk in a Cloud-Native environment.

Zero Trust approaches, where every connection is explicitly authorized and monitored, are thus not only a security paradigm but a tangible compliance tool. This is where Cilium with eBPF comes in: network and security are moved to where they belong in modern infrastructures—into the heart of the operating system and close to the workloads.

Overview of Cilium and eBPF: Networking in the Kernel

Cilium is a Cloud-Native networking and security platform specifically designed for containerized environments like Kubernetes. The core idea: no longer mapping network logic in iptables rule sets, sidecar proxies, or external appliances, but directly in the Linux kernel—with the help of eBPF.

What is eBPF—in Layman’s Terms?

eBPF (extended Berkeley Packet Filter) is a technology that allows small, specialized programs to be safely loaded into the kernel and linked to specific “events,” such as:

• Network packets (incoming/outgoing)
• System calls (syscalls)
• Tracepoints in the scheduler or file system

These programs run in a kind of “sandbox” in the kernel: a verifier checks before execution that they do not perform unsafe operations, do not loop endlessly, and only use allowed resources. As a result, the operating system can be extended very finely and precisely without having to write new kernel modules or recompile the kernel.

For networking, this means: we can implement routing, load balancing, policy enforcement, and observability directly where the packets are processed—without detours and overhead-intensive technology stacks.

Cilium as an eBPF-based CNI

In a Kubernetes environment, Cilium takes on tasks such as:

• Container Networking Interface (CNI) – Pod-to-Pod and Pod-to-Service communication
• Identity-based Network Policies – controlling connections not only by IP/Port but by Service/Pod identity
• In-kernel Load Balancing – without kube-proxy, with significantly less overhead
• Service Mesh functionality – service-to-service security without mandatory sidecar proxies
• Observability & Security – real-time evaluation of network flows, protocols, and metadata

These functions are interesting for compliance because they directly address central control points: Who is allowed to talk to whom? What protocols are used? Are policies enforced? How do I prove to an auditor that the system works as specified?

Compliance-relevant Features of Cilium

Microsegmentation with Network Policies

A core principle of Zero Trust is microsegmentation: instead of one large, “flat” network, workloads are divided into logically separated segments, and strict rules apply between these segments.

Cilium relies on identity-based Network Policies:

• Policies are defined based on labels, services, and Kubernetes identities, not just IP addresses.
• They can cover multiple layers—from classic L3/L4 (IP/Port) to the L7 layer (HTTP methods, paths, DNS names).
• Default-deny strategies can be consistently implemented: everything is forbidden that is not explicitly allowed.

For compliance, this means:

• Clear separation of tenants and environments (e.g., production vs. test).
• Limitation of lateral movements in the event of an attack—a regulatorily required component for damage limitation.
• Documentable, versioned rules: Network Policies are declarative and can be managed in Git (Policy as Code).

Thus, the network becomes a codified security architecture that is verifiable, reproducible, and auditable.

Encryption with WireGuard

Regulations like NIS2, DORA, or ISO 27001 typically require the encryption of sensitive data “in transit.” Cilium supports this natively via WireGuard:

• Pod-to-Pod or Node-to-Node connections can be transparently encrypted.
• Encryption runs in the kernel and is therefore more performant than many “user-space” solutions.
• Key management and tunnel setup are managed automatically, without teams having to maintain their own IPsec configurations.

This allows even internal network segments to be secured in such a way that eavesdropping on data traffic is significantly more difficult—an important point when data centers or cloud environments are operated by external providers.

Observability with Hubble

Transparency is a central pillar of Compliance: it is not just about having security measures, but also being able to prove them. Hubble, the observability subsystem of Cilium, addresses exactly that:

• It records network flows in a structured form: who talks to whom, when, over which protocol, with what result (allowed/blocked).
• The data can be integrated into metric and log systems and visualized there, for example with Grafana.
• Suspicious patterns (unusual connection attempts, many failed attempts, policy violations) become visible.

You can use this information to:

• demonstrate technical and organizational measures to auditors
• forensically analyze security incidents
• establish continuous improvement processes (e.g., tuning policies based on real traffic profiles)

Intrusion Detection & Anomaly Detection

Based on eBPF, Cilium has access to very detailed context information about network events. This enables modern intrusion detection behavior:

• Detecting unusual patterns, such as massive port scans between pods or data streams resembling exfiltration
• Correlation with identities and namespaces, instead of just IPs
• Exporting events to central SIEM or security platforms

For compliance-relevant standards that require Security Incident & Event Management, this is a crucial advantage: events are detected early, enriched with context, and can be transferred into standardized incident processes.

Technical Characteristics of eBPF: Performance, Flexibility, Security

Performance: Network Functions Without Detours

Classic packet processing in container environments often passes through multiple abstraction layers:

• virtual interfaces
• iptables rule sets
• user-space proxies (e.g., kube-proxy, sidecar proxies)

Each layer costs latency and CPU time.

With eBPF, central functions can be executed directly in the kernel:

• Routing decisions are made where the packets arrive.
• Load balancing is done without detours through user-space processes.
• Policy enforcement does not require long iptables chains.

In practice, this results in significantly lower latency and better scalability—an aspect that is particularly relevant with high service density and strict SLAs.

Flexibility: Extendability Without Kernel Patches

Especially in the European context, companies use a variety of Linux distributions and cloud environments. Classic kernel extensions are difficult to standardize here.

eBPF offers:

• Portability: eBPF programs run on different kernel versions without needing to adjust the kernel itself.
• Rapid Innovation: New features can be delivered as user-space components plus eBPF programs—updates are thus significantly less risky.
• Precision: Instead of monolithic firewall rules, pinpoint programs can be created that do exactly what is needed.

This facilitates the construction of standardized platforms across different locations and countries without having to delve deeply into the kernel for every security update.

Security: Verified Programs in the Kernel

A legitimate reflex is: “Program code in the kernel? Isn’t that dangerous?” eBPF addresses this concern by:

• Verifier: A static analyzer checks each program before it is loaded into the kernel. Unsafe programs are rejected.
• Limited Capabilities: eBPF programs do not have unrestricted access to kernel functions; they follow a clearly defined API set.
• Resource Limits: Runtime, stack size, and memory accesses are limited and controlled.

This creates controlled extendability that is fundamentally easier to audit than individual kernel patches or proprietary firewall appliances with opaque rule sets.

Practical Example: Namespace Isolation as a Zero Trust Component

A typical use case in larger organizations is the clean separation of different tenants or domains within a cluster: departments, subsidiaries, development, and production environments. At the Kubernetes level, this separation often occurs through namespaces. Cilium can turn this into a clear, Zero Trust-compliant security perimeter.

1. Define Tenant Model and Namespaces

First, a clear tenant model is created:

• Each tenant or environment receives its own namespaces (e.g., prod-banking, prod-insurance, test-shared).
• Technical services used by multiple tenants (e.g., logging, identity) are operated in dedicated “shared-services namespaces.”

This step is organizational: it is about cleanly capturing responsibilities, data classifications, and dependencies.

2. Identities via Lab