Luca BertonWhy eBPF Changes Kubernetes Networking
Traditional Kubernetes networking relies on iptables — a 25-year-old Linux packet filtering framework. At scale (1,000+ services, 10,000+ pods), iptables rules become unmanageable and introduce latency. Cilium replaces iptables with eBPF (extended Berkeley Packet Filter), running networking logic directly in the Linux kernel with near-zero overhead.
For regulated enterprises, this means three things: better performance, deeper visibility, and identity-aware security policies that go far beyond IP-based network rules.
Cilium Capabilities for Compliance
Identity-Aware Network Policies
Cilium assigns identities to workloads based on Kubernetes labels, not IP addresses. This enables:
- L3/L4 policies: Traditional allow/deny by port and protocol, but using identities instead of IPs
- L7 policies: Allow/deny based on HTTP method, path, headers, gRPC method, Kafka topic, DNS name
- FQDN policies: Control egress by domain name (allow access to
api.stripe.combut block everything else) - Cluster-wide policies: Enforce baseline network security across all namespaces
Compliance impact: NIS2 Article 21(2)(j) requires network segmentation and access control. Cilium's identity-aware policies provide this at L7 granularity.
Transparent Encryption (WireGuard/IPsec)
- Node-to-node encryption: All pod traffic encrypted transparently using WireGuard or IPsec — no application changes
- Zero-config: Enable with a single Helm value (
encryption.enabled=true) - Performance: WireGuard overhead is minimal (~5% throughput reduction vs. unencrypted)
- Compliance evidence: Encryption status visible in Hubble flow logs for audit
Compliance impact: NIS2 Article 21(2)(h) encryption requirements, DORA encryption mandates, and GDPR data-in-transit protection.
Hubble — Network Observability
Hubble is Cilium's built-in network observability platform:
- Flow logs: Every network flow (source, destination, port, protocol, verdict) logged with identity information
- Service map: Real-time visualisation of service-to-service communication
- DNS visibility: All DNS queries and responses logged
- Policy verdict: Every flow tagged with whether it was allowed or denied by which policy
- Prometheus metrics: Network metrics exported for Grafana dashboards
Compliance impact: DORA Article 10 logging requirements, NIS2 detection capabilities, and audit evidence generation.
Cilium vs Calico
| Feature | Cilium | Calico |
|---|---|---|
| Dataplane | eBPF (kernel-native) | iptables or eBPF (newer) |
| L7 policies | Native (HTTP, gRPC, Kafka, DNS) | Limited (requires Envoy for L7) |
| Observability | Hubble (built-in, deep visibility) | Flow logs (basic, Calico Enterprise for more) |
| Encryption | WireGuard or IPsec (transparent) | WireGuard (newer versions) |
| Service mesh | Built-in (sidecar-less) | No (use Istio/Linkerd) |
| Maturity | CNCF Graduated, Isovalent (Cisco) | CNCF project, Tigera (enterprise) |
Kubernetes Recipes
A practical guide for container orchestration and deployment by Grzegorz Stencel & Luca Berton (Apress).
Watch on Skillshare →Deployment for Regulated Environments
- Enable WireGuard encryption from day one — no reason to run unencrypted in regulated environments
- Deploy Hubble with flow log retention aligned to your audit requirements (1 year minimum for DORA)
- Start with deny-all default and build allow-list policies — zero trust networking from the start
- Use cluster-wide policies for baseline controls (no internet egress, DNS logging, metadata API protection)
- Export Hubble metrics to Grafana for compliance dashboards and SLO monitoring