# Cilium: eBPF-Based Networking, Security, and Observability for Kubernetes

> Cilium is a Kubernetes CNI plugin that uses eBPF to enforce network policies at L3 through L7, replace kube-proxy with hash-table-based load balancing, and provide deep observability through its Hubble component. It is a graduated CNCF project, currently stable at v1.20.2.

**cilium/cilium** — eBPF-based Networking, Security, and Observability

- Repository: https://github.com/cilium/cilium
- Website: https://cilium.io
- Stars: 25,553 · Forks: 4,105
- Language: Go
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/cilium-cilium

## The eBPF Foundation: Why Cilium Differs from Traditional CNIs

Traditional Kubernetes networking relies on iptables and kube-proxy. iptables processes network rules as a linear chain, and as the number of services grows, the chain lengthens. kube-proxy implements service load balancing by rewriting packet destinations using iptables rules. Both approaches have known scaling limits and limited visibility into application-layer traffic.

Cilium replaces this stack with eBPF. eBPF is a Linux kernel technology that allows programs to be inserted at specific integration points in the kernel (network IO, application sockets, tracepoints) without modifying the kernel source or loading a kernel module. The README describes eBPF as highly efficient and flexible, and points to ebpf.io for technical background.

For Cilium, eBPF changes what is possible at each layer. Load balancing uses hash tables in eBPF rather than iptables chains, which the README says allows for almost unlimited scale. Network policy enforcement happens directly in the data path rather than as a set of iptables rules evaluated per-packet. Observability is collected at the kernel level, capturing traffic that passes through the data plane without requiring a sidecar proxy in each pod.

The README notes that Cilium provides a simple flat Layer 3 network with the ability to span multiple clusters in either native routing or overlay mode. The choice of mode affects the infrastructure requirements: overlay mode works on almost any network, while native routing mode requires the physical network to route pod IP addresses.

## Two Networking Modes: Overlay and Native Routing

Cilium supports two deployment networking models, and the choice between them is an infrastructure decision made at install time.

Overlay networking uses encapsulation (VXLAN or Geneve) to create a virtual network across all Kubernetes nodes. The README states this works on almost any network infrastructure, since the only requirement is IP connectivity between hosts. Pod IP addresses are encapsulated inside the overlay and do not need to be routable on the underlying network. This is the safer default for cloud environments where you do not control the physical network layer.

Native routing mode uses the regular routing table of the Linux host. Pod IP addresses must be routable on the physical network, which means integrating with a cloud router, a routing daemon, or IPv6-native infrastructure. The README notes that Cilium can automate route learning and advertisement in common topologies: L2 neighbor discovery when nodes share a layer 2 domain, or BGP when routing across layer 3.

Beyond these two modes, the README lists advanced networking features: distributed load balancing for pod-to-pod and pod-to-external traffic, integrated ingress and egress gateways, bandwidth management, and service mesh capabilities.

The multi-cluster support means that Cilium can span workloads across more than one Kubernetes cluster, with network policies applied consistently. This is relevant for organizations that run production and staging clusters and want uniform policy enforcement across both.

## Installing Cilium on a Kubernetes Cluster

Cilium's installation documentation is at docs.cilium.io. The README does not reproduce installation commands inline; it directs readers to the Cilium Upgrade Guide for upgrades to new minor releases.

The current stable releases, their image pull tags, and their release dates as listed in the README:

| Branch | Date | Image |
|---|---|---|
| v1.20 | 2026-09-15 | quay.io/cilium/cilium:v1.20.2 |
| v1.19 | 2026-09-15 | quay.io/cilium/cilium:v1.19.8 |
| v1.18 | 2026-09-15 | quay.io/cilium/cilium:v1.18.14 |

Images are distributed from quay.io and cover both AMD64 and AArch64 architectures. For development and testing, a daily CI image is available:

```
quay.io/cilium/cilium-ci:latest
```

This CI image is explicitly not for production use. Pre-release candidates for the upcoming v1.21 are at:

```
quay.io/cilium/cilium:v1.21.0-pre.2
```

The repository includes a cilium-cli/ subdirectory with the CLI source. The CLI is the standard tool for managing a Cilium installation, running connectivity tests, and performing upgrades. The build system uses Make; running `make all` at the repository root compiles the full project from source.

For Kubernetes deployments, the repository includes Helm charts under the charts/ directory. The install/ directory contains additional Kubernetes manifests. The actual Helm install procedure is in the Cilium documentation rather than in the README.

## L7 Policy Enforcement and Identity-Based Security

Cilium's security model differs from traditional IP-based network policies in one important way: it uses identity rather than IP address as the primary policy anchor.

The README states that Cilium implements an identity-based security model that is decoupled from network addressing. In a Kubernetes cluster, pod IP addresses change constantly as pods are rescheduled. Policies based on IP addresses require continuous updates to stay current. Cilium assigns identities to workloads based on labels and enforces policy based on those identities, which remain stable even as IP addresses change.

Policy enforcement is L7-aware, meaning Cilium can make allow/deny decisions based on application-layer attributes, not just IP and port. For HTTP traffic, a policy could allow GET requests to /api/health while blocking POST requests to /admin. For databases, Cilium can parse protocol-specific requests.

This L7 capability requires the Cilium proxy component (cilium/proxy in the repository) to intercept and inspect traffic. The go.mod file shows this as github.com/cilium/proxy at a commit from September 2026. The README describes this as policy enforcement on L3-L7 using an identity-based security model.

The egress gateway feature allows outbound traffic from pods to be directed through a specific node IP, which is useful for compliance requirements where external systems need a fixed source IP address from the Kubernetes cluster.

## Hubble: Built-In Network Observability

Hubble is Cilium's observability component. The repository includes hubble/ and hubble-relay/ as subdirectories, indicating that Hubble is developed and shipped as part of the Cilium monorepo.

The README states that Cilium provides deep network and security visibility and monitoring through Hubble. Because eBPF-based data collection happens at the kernel level, Hubble can capture all traffic flowing through the Cilium data plane without deploying a sidecar proxy in each pod. This is architecturally different from service mesh approaches like Istio, where observability requires a sidecar container in every pod.

Hubble exposes the observability data through the hubble-relay component, which aggregates data from all nodes. The CLI tool (from the cilium-cli/ subdirectory) can query Hubble for flow data, policy verdicts, and network maps.

The examples/hubble/ directory in the repository contains configuration examples for Hubble deployments. The examples/policies/ directory contains network policy examples in the Kubernetes CRD format that Cilium uses.

For teams coming from iptables-based CNIs, Hubble's ability to show which workload identities are communicating (rather than which IP addresses) is a qualitative change in how network debugging works. An `allow` or `drop` verdict in Hubble identifies the source and destination by Kubernetes labels, not by ephemeral pod IPs.

## Release Policy, Upgrade Cost, and License

The Cilium community maintains the last three minor releases as stable branches. At time of this article, those are v1.18, v1.19, and v1.20. Older minor releases are end-of-life. The README describes this explicitly: stable releases for the last three minor Cilium versions; older releases are considered EOL.

The three-release window means an organization running v1.17 has no supported upgrade path other than moving to a current branch. The Cilium Upgrade Guide (referenced in the README at docs.cilium.io) is the required reading before any minor version upgrade, since eBPF data-plane changes between minor versions can require careful sequencing.

Starting with Cilium 1.13.0, all images include a Software Bill of Materials (SBOM) in SPDX format. This is documented in the README and is relevant for organizations with supply-chain security requirements. The SBOM documentation is at docs.cilium.io/en/latest/configuration/sbom/.

The license is Apache-2.0 for the main Cilium codebase. The go.mod shows several Cilium sub-projects (cilium/ebpf, cilium/hive, cilium/statedb, cilium/proxy) as direct dependencies, each under their own licenses. For organizations that perform license audits, the SBOM provides the bill of materials that maps each dependency to its license.

The last push to the repository was on 2026-09-25, three days before this article. Release v1.20.2 was published on 2026-09-16. The pace of patch releases across three maintained branches suggests a project with significant operational investment in stability.

## Conclusion

Cilium is a strong choice for Kubernetes clusters where standard kube-proxy performance is a bottleneck, where you need L7-aware network policies, or where the networking and security layers need to be observable at a level that iptables-based tools cannot provide. The three-release maintenance window (v1.18, v1.19, v1.20) means older minor releases reach end-of-life on a predictable schedule, and upgrades need to follow the documented Cilium Upgrade Guide to avoid data-plane disruption. Teams on managed Kubernetes services should verify that the service allows replacing the CNI and kube-proxy before committing. The SBOM in SPDX format (included since v1.13) and the Apache-2.0 license make Cilium a viable choice for environments with strict supply-chain requirements.

## FAQ

### What is Cilium used for?

Cilium is used as a CNI plugin for Kubernetes clusters to provide networking, network policy enforcement (including L7-aware policies), and observability. It can replace kube-proxy using eBPF-based hash tables for service load balancing, and its Hubble component provides per-flow network visibility without requiring sidecar proxies.

### How do I install Cilium on a Kubernetes cluster?

The README directs readers to docs.cilium.io for installation steps. The current stable image is quay.io/cilium/cilium:v1.20.2. The repository includes Helm charts in the charts/ directory, and the cilium-cli in cilium-cli/ is the standard management tool. The README explicitly says to consult the Cilium Upgrade Guide before upgrading to a new minor release.

### How do I use Cilium Hubble?

Hubble is Cilium's observability component, developed within the same repository under the hubble/ and hubble-relay/ subdirectories. It collects network flow data at the eBPF level from all nodes, accessible through the cilium-cli tool. Configuration examples are in the examples/hubble/ directory.

### How do I install the Cilium CLI?

The CLI source is in the cilium-cli/ subdirectory of the main Cilium repository. The README references cilium-cli as part of the standard Cilium toolchain; installation steps for the pre-built binary are in the Cilium documentation at docs.cilium.io.

## Sources

- [Official documentation](https://cilium.io)
- [Official README](https://github.com/cilium/cilium#readme)
- [Project repository](https://github.com/cilium/cilium)
- [Release notes](https://github.com/cilium/cilium/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cilium-cilium