Cilium
eBPF-based networking, security, and observability platform for Kubernetes. Cilium serves as the CNI (Container Network Interface) plugin with built-in Layer 3-7 network policies, load balancing, service mesh capabilities (without sidecar proxies), and deep network observability via Hubble. Uses Linux eBPF for high-performance packet processing at the kernel level, replacing traditional iptables-based networking with lower overhead. CNCF graduated project, used by major cloud providers (AWS, Google, Azure EKS/GKE/AKS now all support Cilium).
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Apache 2.0, CNCF graduated. eBPF-based security enforcement at kernel level. L7 policies with mTLS. Hubble observability for security auditing. Isovalent Enterprise adds FIPS compliance. Strong security track record.
⚡ Reliability
Best When
You need advanced Kubernetes networking with L7 policies, built-in service mesh, and deep network observability using eBPF — particularly for security-sensitive or performance-critical workloads.
Avoid When
You have an older Linux kernel, need simple L3 networking only, or lack ops expertise to manage Cilium's more complex configuration.
Use Cases
- • Enforce fine-grained Layer 7 network policies (allow HTTP GET /api but not POST) between Kubernetes pods using Cilium NetworkPolicy resources
- • Implement service mesh capabilities (mutual TLS, load balancing, observability) without sidecar proxy overhead using Cilium's eBPF-based approach
- • Monitor all network flows between services using Hubble (Cilium's observability layer) for security auditing and debugging
- • Replace kube-proxy for high-performance Kubernetes service load balancing using eBPF-native implementation
- • Query Cilium's REST API and Hubble API from agent monitoring workflows to understand network topology and policy enforcement
Not For
- • Non-Kubernetes networking — Cilium is designed for Kubernetes; traditional datacenter networking uses different tools
- • Teams without Linux kernel 4.19+ — eBPF requirements set a minimum kernel version
- • Simple deployments not needing L7 policies or observability — Flannel or Calico are simpler for basic L3 networking
Interface
Authentication
Cilium's primary interface is Kubernetes CRDs — access via Kubernetes RBAC. Cilium agent REST API runs on each node and is protected by node network access. Hubble UI and Relay use mTLS for service-to-service auth.
Pricing
Apache 2.0 CNCF graduated project. Isovalent (Cisco-acquired) offers enterprise features and support. Core Cilium is free and production-ready.
Agent Metadata
Known Gotchas
- ⚠ Cilium requires Linux kernel 4.19+ — older environments (legacy VMs, some cloud instance types) are not supported
- ⚠ Migrating from an existing CNI (Flannel, Calico) to Cilium requires a rolling node-by-node migration — plan for maintenance window
- ⚠ CiliumNetworkPolicy syntax extends Kubernetes NetworkPolicy with L7 rules — mixing both resource types on the same cluster requires careful coordination
- ⚠ Hubble requires separate installation and configuration — Cilium networking works without Hubble, but observability requires Hubble Relay and UI
- ⚠ eBPF map limits can be hit in very large clusters — default map sizes may need tuning for clusters with many pods or services
- ⚠ Cilium's identity model uses labels, not IP addresses — agents querying network policy must understand label-based identity
- ⚠ Node-level cilium agent REST API (default port 9090) is localhost-only — access requires kubectl exec or privileged pod
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Cilium.
Scores are editorial opinions as of 2026-03-06.