# Cilium 1.20: A New Era of Extensible Networking, Traffic Management, and Security for Kubernetes
September 2026 marked the release of Cilium 1.20, the second major open source release of the year and the latest step forward for the cloud-native networking layer that powers thousands of production clusters worldwide. This release centers on three broad themes: expanding Gateway API as a comprehensive north-south traffic management layer, making Cilium itself a platform that cloud providers can extend through a new plugin architecture, and continuing to push innovation while aligning with upstream Kubernetes standards.
Below is a walkthrough of the headline features, what they mean for your cluster, and how they fit into the bigger picture.
—
## 1. ENI IPAM Mode Gains Full IPv6 Support on AWS
One of the longest-standing feature gaps for Cilium on AWS has been the lack of IPv6 support when running in Elastic Network Interface (ENI) IPAM mode. Until now, pods in EKS clusters using ENI IPAM received only IPv4 addresses, even though the underlying AWS infrastructure already supports dual-stack networking.
Cilium 1.20 closes this gap. ENI IPAM is now a beta feature that can allocate and assign IPv6 prefixes to worker nodes through AWS Prefix Delegation. Each node receives a /80 IPv6 prefix, and the Cilium agent hands out individual pod addresses from that range.
**Getting started is straightforward:**
“`yaml
ipam:
mode: eni
eni:
enabled: true
ipv6:
enabled: true
“`
Once configured, pods on EKS boot up with dual-stack VPC-routable addresses, giving you full IPv6 connectivity without any changes to your existing CNI configuration. This means workloads can communicate over IPv6 end-to-end, including cross-AZ and cross-VPC traffic where the underlying AWS networking supports it.
The feature was contributed primarily by engineers at Datadog, one of the most active organizations in the Cilium community, who built and tested the implementation at scale.
—
## 2. Automatic Datapath Mode Selection Makes Netkit Easy to Adopt
Netkit, the next-generation pod networking device introduced in earlier Cilium releases, replaces the traditional veth pair and brings pod networking throughput to host-level performance. Meta has already rolled it out across millions of containers, and ByteDance reported a 10% performance improvement during its deployment.
The challenge with netkit was that it required a Linux kernel version 6.8 or newer. On fleets with mixed kernel versions, operators had to either disable netkit entirely or carve nodes into separate pools based on kernel version, adding significant operational complexity.
Cilium 1.20 solves this with a new `auto` mode for `bpf.datapathMode`. Each Cilium agent probes the host kernel at startup, automatically uses netkit when the kernel supports it, and silently falls back to veth on older kernels.
“`
Device Mode: netkit [Configured: auto]
“`
Operators can verify which mode each node actually landed on through `cilium-dbg status` and the `cilium_feature_datapath_config` metric. The default remains veth for backward compatibility, so nothing changes until you opt in, but the path to netkit adoption has never been simpler.
—
## 3. Datapath Plugins: A New Extension Architecture
Historically, extending or instrumenting Cilium’s eBPF datapath meant either submitting changes upstream or maintaining a full fork of the Cilium codebase. Both approaches are high-effort, and a fork means carrying datapath patches across every Cilium release.
Cilium 1.20 introduces **datapath plugins** in beta. Third-party code can now instrument Cilium’s eBPF datapath as its own plugin, running as a separate process that Cilium communicates with at runtime. Because each plugin is its own container image, it can be built, versioned, and rolled out independently of Cilium itself. A plugin crash will not take down the Cilium agent, and upgrades happen on the plugin’s own cadence.
Plugins register themselves through a lightweight `CiliumDatapathPlugin` custom resource:
“`yaml
apiVersion: cilium.io/v2alpha1
kind: CiliumDatapathPlugin
metadata:
name: example
spec:
attachmentPolicy: Always
version: 0.0.
“`
This opens the door for cloud providers and specialized vendors to ship their own networking, observability, or security extensions that evolve independently of the Cilium release cycle, without the burden of maintaining a fork.
—
## 4. Per-Pod Source IP Verification Control
Source IP verification is a critical security mechanism in Kubernetes. By default, Cilium ensures that a pod may only send packets whose source IP matches its own address, preventing compromised or misbehaving workloads from spoofing another pod’s identity.
Until now, this was controlled by a single cluster-wide switch. If a specific workload, such as a NAT gateway, firewall appliance, VPN endpoint, or Tailscale node, needed to emit packets with a different source IP, operators had to disable source IP verification for the entire cluster, weakening anti-spoofing protection for all workloads.
Cilium 1.20 makes this a per-pod, opt-in decision controlled at two levels:
– A cluster administrator permits the override for a namespace by annotating it with `config.cilium.io/delegate-source-ip-verification: “true”`.
– A pod owner can then opt that specific workload out by annotating the pod with `config.cilium.io/disable-source-ip-verification: “true”`.
Both annotations are required, so a namespace owner cannot quietly disable anti-spoofing for the entire namespace. The protection stays enabled everywhere except for the specific workloads that explicitly opt in.
—
## 5. In-Place Migration from Cluster-Pool to Multi-Pool IPAM
Multi-pool IPAM has become the preferred way to hand out pod IPs in Cilium. Instead of drawing every address from a single flat cluster-wide range, operators carve the space into named pools and assign them per namespace, per workload, or per tenant.
The problem was migration. If a cluster was already running the default cluster-scope IPAM mode, moving to multi-pool required standing up a fresh cluster and migrating workloads, which is disruptive and expensive.
Cilium 1.20 adds an in-place migration path. Operators can switch an existing cluster from `cluster-pool` to `multi-pool` using the operator option `enable-cluster-pool-to-multi-pool-migration`, with no rebuild and no re-IP-ing of existing workloads.
—
## 6. Traffic Distribution: PreferSameZone and PreferSameNode
Introduced in Cilium 1.16, Service Traffic Distribution allows users to keep Service traffic close to its origin, reducing latency and avoiding cross-zone data transfer charges. Until now, Cilium only supported the `PreferClose` value, indicating a preference for topologically proximate endpoints.
Cilium 1.20 expands this with two new values aligned with upstream Kubernetes:
– `PreferSameZone` keeps traffic within the client’s availability zone while a healthy backend is available there.
– `PreferSameNode` prefers a backend running on the very same node as the client.
Both values gracefully fall back to the rest of the cluster’s backends when no local one is healthy, preserving availability while still gaining the locality benefit. Because this uses the standard Kubernetes `trafficDistribution` field rather than a Cilium-specific annotation, the same Service spec behaves consistently across conformant implementations.
—
## 7. EndpointSlice Weights for Maglev Load Balancing
Maglev, Cilium’s consistent hashing load balancer introduced in Cilium 1.10, provides minimal disruption during node or backend changes. However, there was no supported way to give some backends a larger share of traffic or to gracefully drain a group of backends for maintenance.
Cilium 1.20 introduces endpoint weight support via the `service.cilium.io/weight` annotation on EndpointSlice objects. The weight applies to every backend in that slice, with valid values from 0 to 65535. Weights are relative, so they do not need to sum to 100.
A classic 70/30 weighted split across two manually managed EndpointSlices becomes a simple annotation change:
“`yaml
annotations:
service.cilium.io/weight: “70” # applies to every backend in this slice
“`
The special case of weight 0 provides a clean, connection-preserving drain: existing connections continue to work, but the backends are removed from the Maglev lookup table so no new connections are steered to them. Invalid values are silently ignored, so a typo never takes a Service down.
—
## 8. Gateway API Advances: ExternalAuth, TCPRoute, UDPRoute, and ListenerSets
Cilium 1.20 upgrades its Gateway API support from v1.4 to v1.6, implementing capabilities that graduated across those releases. This positions Gateway API as a much broader traffic management layer than before.
### ExternalAuth Filter
The ExternalAuth filter allows gateway-level authentication and authorization before a request reaches the application. When attached to an HTTPRoute, the gateway checks every matching request with an external authorization service. Unauthenticated callers receive a redirect to a login page (302) or a block (401/403). Once authenticated, the authorizer can inject identity headers so the application makes authorization decisions without handling credentials directly.
This works for very different callers on the same gateway: browser-based humans using SSO, CI jobs presenting JWTs, and AI agents authenticating with service accounts.
### TCPRoute and UDPRoute
With these two new route types, Cilium can now manage L4 traffic, including databases, DNS, message brokers, VoIP, gaming, and streaming media, entirely through Gateway API. Prior to this release, plain TCP and UDP services had to be exposed using raw LoadBalancer or NodePort Services, stepping outside the Gateway API model.
### ListenerSets
ListenerSets solve a common multi-tenant ownership problem. The platform team controls the shared Gateway, but application teams own the endpoints behind it. ListenerSets allow application teams to attach and manage additional Listeners from their own namespaces, sharing the parent Gateway’s address while the platform team retains control over who can extend it.
### Additional Improvements
Cilium 1.20 also adds native support for the Gateway API CORS filter, complete redirect code coverage including 303, 307, and 308, and the ability for `CiliumGatewayClassConfig` to control HTTP Server response headers through `OVERWRITE`, `APPEND_IF_ABSENT`, and `PASS_THROUGH` modes.
—
## 9. ztunnel: Sidecarless Mutual TLS Becomes More Operational
Cilium 1.19 introduced ztunnel, a per-node proxy that provides sidecarless mutual TLS for pod-to-pod traffic. Cilium 1.20 continues this work with several operational improvements:
– **Configurable certificate authority**: The default `internal` mode runs ztunnel mTLS without requiring SPIRE, while `spire` mode uses SPIFFE workload identities for teams that want the CNCF-graduated SPIFFE and SPIRE identity stack.
– **New Prometheus metrics**: Enrollment and connection health metrics give operators visibility into mTLS adoption and issues.
– **Improved dashboard integration**: Metrics are combined with Kubernetes workload data to show protected workloads, enrollment activity, failures, and connection state per node.
The original mutual authentication feature in Cilium has been marked as deprecated, with removal planned for a later release, as ztunnel becomes the clear successor.
—
## 10. Kubernetes ClusterNetworkPolicy Support
Kubernetes NetworkPolicy is namespaced and additive, which means cluster administrators have no native way to enforce a rule that takes precedence over namespaced policies. The upstream `network-policy-api` subgroup has been working on this gap, and its latest iteration consolidates earlier proposals into the `ClusterNetworkPolicy` API.
Cilium 1.20 implements `ClusterNetworkPolicy`. It is cluster-scoped and tiered: an `Admin` tier that takes precedence over namespaced NetworkPolicy, and a `Baseline` tier that acts as a default which namespaced policy can override. Policies can select subjects by namespace or pod, set priority levels, and define ingress/egress rules with `Accept`, `Deny`, or `Pass` actions. Selectors support `matchExpressions` in addition to `matchLabels`, enabling set-based rules.
This gives platform teams the guardrails they need: enforce a cluster-wide baseline, or hard-deny traffic that no namespace can re-open.
—
## 11. Cluster-Mesh Policy Entity and Policy Map Aggregation
When writing Cilium Network Policies that allow traffic from anywhere in a Cluster Mesh, operators previously had to enumerate remote clusters by name or use broad label selectors, since the `cluster` entity only covered the local cluster. Such policies were verbose, error-prone, and costly at scale because each remote identity consumed its own BPF policy-map entry.
Cilium 1.20 adds a `cluster-mesh` policy entity that selects every endpoint in every meshed cluster with a single word. Writing `fromEntities: cluster-mesh` once keeps matching as clusters join or leave the mesh. Additionally, both `cluster` and `cluster-mesh` identities now aggregate into far fewer policy-map entries, so mesh-wide rules are also the cheaper ones to enforce at scale.
—
## 12. Hubble Policy Correlation for Audit Verdicts
When a flow was dropped under default-deny or logged under Policy Audit Mode, Hubble showed the drop but left the policy fields empty. Operators could see that a flow was denied but not which policy was responsible.
Cilium 1.20 adds policy correlation for audit verdicts. Audit flows now populate the `ingress_allowed_by / egress_allowed_by` and `ingress_denied_by / egress_denied_by` fields, so operators can see exactly what would have denied the flow before flipping enforcement on.
—
## 13. MCS-API Reaches Stable Support in ClusterMesh
The Multi-Cluster Services API provides a portable, vendor-neutral standard for cross-cluster service discovery. Cilium had offered beta MCS-API support in earlier releases, and Cilium 1.20 promotes this to stable.
Application teams can make a Service discoverable across clusters by creating a `ServiceExport` resource. Workloads in any connected cluster can then reach it through the standard MCS-API DNS name `web.default.svc.clusterset.local`. The same application manifests can be used with any conformant implementation.
—
## 14. CNI Binary Size Reduced by 79%
The `cilium-cni` plugin, installed on every node and called by the kubelet to wire up pods, was 76 MB in Cilium 1.19. In Cilium 1.20, the plugin no longer imports unnecessary Go packages from the agent codebase, bringing the same binary down to 16 MB — a 79% reduction.
A smaller binary on every node means a smaller image layer to pull and less data to copy during each CNI installation, which matters at scale.
—
## 15. BGP Tooling Improvements
Cilium’s BGP support, powered by GoBGP, receives improved debugging experience in Cilium 1.20. On-agent BGP commands are now surfaced through `cilium-dbg shell — bgp/…`, with a new `bgp/route-policies` command showing the route policies actually programmed into GoBGP. The `bgp/peers` command gains a `–format` option supporting table, JSON, and detailed views with per-peer timers, negotiated capabilities, and graceful restart state.
Note: the old `on-agent cilium-dbg bgp` subcommands and the local REST BGP API are deprecated in 1.20. Users should migrate to the new hive-shell equivalents.
—
## FAQ
**What is Cilium?**
Cilium is an open source CNI (Container Network Interface) plugin for Kubernetes that provides networking, security, and observability using eBPF. It is a CNCF graduated project.
**Is Cilium 1.20 a long-term support release?**
Cilium follows a regular release cadence with multiple major releases per year. Check the official Cilium documentation for support timelines and maintenance windows for each release.
**What kernel version is required for netkit?**
Netkit requires Linux kernel 6.8 or newer. The new `auto` datapath mode in Cilium 1.20 handles mixed fleets by falling back to veth on older kernels automatically.
**Does ENI IPv6 support work in all AWS regions?**
ENI IPAM with IPv6 is available in AWS regions that support dual-stack networking for EKS. Check the AWS and Cilium documentation for region-specific availability.
**Can I use datapath plugins with any Cilium deployment?**
Datapath plugins are currently in beta. They require a Cilium agent that supports the `CiliumDatapathPlugin` CRD and a plugin image that follows the plugin interface specification. Review the documentation for requirements and limitations before deploying in production.
**What happens to the old mutual authentication feature?**
The legacy mutual authentication feature has been marked as deprecated in Cilium 1.20 and is scheduled for removal in a future release. Users should plan to migrate to ztunnel.
**Is Gateway API support in Cilium production-ready?**
Many Gateway API features in Cilium 1.20 have reached stable or GA status, but some features remain experimental. Check the Cilium documentation for the maturity level of each Gateway API feature before using it in production.
**How do I migrate from cluster-pool to multi-pool IPAM?**
Use the `enable-cluster-pool-to-multi-pool-migration` operator option in Cilium 1.20. This performs an in-place migration with no downtime and no re-IP-ing of existing pods.
**What is the difference between MCS-API and Cilium Global Services?**
MCS-API is a portable, vendor-neutral Kubernetes standard for cross-cluster service discovery. Cilium Global Services is Cilium’s own proprietary solution. Cilium 1.20 supports both, giving users a choice between a standard API and Cilium-native features.
**Where can I learn more?**
The Cilium documentation, the Cilium blog, and the CiliumCon talks are the best resources for detailed guides, tutorials, and deep dives into each of these features.
—
## Conclusion
Cilium 1.20 represents a significant evolution for the project. Gateway API is no longer just an Ingress replacement but a full-featured traffic management layer capable of handling authentication, L4 routing, cross-namespace delegation, and fine-grained load distribution. The new datapath plugin architecture transforms Cilium from a self-contained networking appliance into an extensible platform that cloud providers can customize without forking. At the same time, Cilium continues to align with upstream Kubernetes standards through stable MCS-API support, ClusterNetworkPolicy, and consistent use of standard Kubernetes APIs.
For operators, the practical benefits are immediate: easier netkit adoption through automatic mode selection, IPv6 on AWS ENI, simpler IPAM migration, reduced CNI binary size, better debugging tools, and more granular security controls that do not force trade-offs across the cluster.
The Cilium community continues to grow well beyond the code itself, with organizations like Asana, Etraveli, Michelin, OpenAI, SUSE, Telefónica’s acens, and Zynga running Cilium in production at scale. Community events such as CiliumCon and the Cilium Developer Summit provide opportunities to connect, learn, and share experiences.
Thank you for reading
