
Cilium 1.20: Gateway API Gets Authentication, TCP Gets a Route, and the Node Agent Shrinks 79%
Cloud Platform EngineeringCilium 1.20 is a meaningful release — not because any single feature is a category-changer, but because the cumulative direction is clear: Cilium is replacing the patchwork of load balancers, service meshes, policy engines, and auth proxies that most Kubernetes clusters have assembled over time, with a single eBPF-native control plane that handles all of it.
That’s the lens through which the 1.20 feature set makes sense.
Gateway API ExternalAuth
The most operationally significant addition in 1.20 is Gateway API support for external authorization. Before this release, handling authentication at the gateway layer required operating a separate auth proxy (Envoy with ext_authz, nginx with auth_request, or similar) outside the Gateway API configuration surface.
Cilium 1.20 lets platform teams define an external authorizer as part of the Gateway API configuration. Requests are checked against the external service — which can redirect browsers to SSO flows, validate JWT tokens for service-to-service calls, or gate CI/CD agent access — before reaching the application. The platform team manages the policy in the same API they use for routing. Application teams don’t build auth into their services.
The breadth of caller types the announcement calls out is notable: browsers, CI jobs, and AI agents. That’s not a generic statement — it reflects that modern platform teams now need to gate traffic from automated agents with the same tooling they use for human-initiated requests.
TCPRoute and UDPRoute
Cilium 1.20 extends Gateway API beyond HTTP to manage Layer 4 services through the same declarative Kubernetes API. TCPRoute handles services like databases, message queues, and custom TCP protocols. UDPRoute handles DNS servers, VoIP, gaming services, and similar.
The operational impact is straightforward: teams managing databases or DNS alongside HTTP services no longer need to drop down to LoadBalancer or NodePort resources to expose them. The configuration surface stays consistent. Portability across clusters improves — a TCPRoute or UDPRoute works the same way on any Cilium cluster without provider-specific annotations.
ENI IPAM for IPv6 on AWS EKS
AWS EKS users running Cilium in ENI mode can now allocate VPC-routable IPv6 addresses to pods via Prefix Delegation. This closes a four-year-old feature gap and enables full dual-stack operation without architectural workarounds.
Required configuration: ipam.mode: eni, eni.enabled: true, and ipv6.enabled: true. For EKS clusters already in ENI mode, this is a flag-flip migration rather than an architectural change.
Operational Improvements
cilium-cni binary: 76MB → 16MB (79% reduction). The node agent binary that runs on every Kubernetes node shrank significantly. For clusters that frequently rotate nodes — autoscaling, spot instances, Karpenter-managed fleets — this reduces node initialization time and bootstrap overhead.
Automatic datapath mode selection (netkit auto). Mixed kernel version clusters — common in long-running production environments where nodes have been upgraded incrementally — now automatically use netkit where the kernel supports it and fall back to veth elsewhere. This simplifies deployment without requiring operators to track per-node kernel versions.
Datapath Plugins (Beta). Cloud providers can now extend Cilium’s eBPF datapath without maintaining forks. The immediate beneficiary is Azure (AKS), where Microsoft’s networking requirements have historically required divergent Cilium builds. This moves Cilium closer to a stable extension point for cloud-provider customization rather than a fork-and-diverge baseline.
Kubernetes ClusterNetworkPolicy. Cluster-wide security baselines that namespace administrators cannot override. This is the missing piece for enterprises that need to enforce network policy at the cluster level without relying on namespace-scoped NetworkPolicy objects that any namespace admin could modify.
The So What
Cilium 1.20 continues to make the case that CNI selection at cluster provisioning time is a consequential architectural decision. A cluster running Cilium 1.20 has external auth, L4 route management, dual-stack IPv6, and cluster-wide network policy available from the same control plane — no additional service mesh required, no separate auth proxy, no fork of the CNI to accommodate cloud-provider requirements.
Platform teams evaluating Cilium as a full networking control plane — rather than just a CNI — have more surface area to work with in 1.20 than any prior release. The direction of the project is consistent enough at this point to plan around.
Source: CNCF Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →