Cilium 1.20 Expands Gateway API and Opens eBPF Datapath for Kubernetes

Cilium 1.20 has been released with broader Kubernetes Gateway API support, an extensible eBPF datapath and further work on sidecarless mutual TLS. The release also makes the newer netkit network device easier to introduce across Kubernetes fleets that run different Linux kernel versions.

In the release announcement, Cilium engineers Nico Vibert and Donia Chaiehloudj describe Gateway API as a "much broader traffic management layer" in version 1.20. Cilium moves from Gateway API 1.4 to 1.6, adding ExternalAuth, ListenerSets, CORS filtering, TCPRoute and UDPRoute. These additions bring HTTP authentication and non-HTTP services such as databases and DNS under the same Kubernetes API used for web and gRPC traffic.

According to Vibert and Chaiehloudj, ExternalAuth allows an HTTPRoute to consult an external authorisation service before sending a request to an application. Depending on the response, the gateway can forward the request, redirect a user to a login page, or reject it. The authoriser can also pass identity headers to the application. TCPRoute and UDPRoute remove the need to fall back to LoadBalancer or NodePort Services for plain Layer 4 traffic.

ListenerSets address a separate ownership problem. Application teams can add listeners from their own namespaces while a platform team retains control of the shared Gateway and decides which namespaces may extend it. Platform engineer Mohamed Salem BEN ATAIA wrote on LinkedIn that ListenerSets close the gap between teams owning Routes and needing a central change for a new hostname or port. In his assessment, "It removes a platform bottleneck."

"Gateway API becomes a much broader traffic management layer."
Nico Vibert and Donia Chaiehloudj

The direction is consistent with work elsewhere in Kubernetes networking. InfoQ previously reported that the Kubernetes community recommends Gateway API as organisations move away from the retired Ingress NGINX controller. AWS also reached general availability with Gateway API support in its Load Balancer Controller, covering HTTP and gRPC through Application Load Balancer and TCP and UDP through Network Load Balancer. Cilium's implementation differs in that the same project can provide the CNI, service networking and gateway functions.

A second change opens Cilium's eBPF datapath to third-party plugins. Previously, cloud providers that needed custom instrumentation or networking behaviour had to contribute the change upstream or maintain a fork. A plugin now runs as a separate process and can be built, versioned and upgraded independently. Cilium communicates with it through a small custom resource and a gRPC interface.

"Datapath plugins, developed by Google, make Cilium less like a sealed networking appliance and more like a network operating system."
Nico Vibert and Donia Chaiehloudj

The plugin mechanism is beta and is not presented as a general extension system for ordinary cluster users. Cilium's documentation says it is intended for operators with detailed knowledge of Cilium's internals. It also warns that a plugin can break Cilium or weaken security, and that maintainers may need to update their code as Cilium's internal architecture changes.

Cilium 1.20 also introduces automatic selection of the pod datapath. Setting bpf.datapathMode=auto makes each agent test its host at start-up, use netkit where the kernel supports it, and fall back to a traditional veth pair elsewhere. Netkit requires Linux 6.8 or later. The default remains veth, so existing installations do not change unless an operator opts in. Vibert and Chaiehloudj say this avoids dividing mixed fleets into separate node pools solely to select a datapath mode.

The fourth main area is ztunnel, the per-node proxy introduced in Cilium 1.19 for sidecarless mutual TLS. Version 1.20 adds a choice between an internal certificate authority and SPIRE-issued workload identities, together with Prometheus metrics for enrolment and connection health. Ztunnel holds a new connection while it establishes TLS 1.3 over an HBONE tunnel, avoiding the first-packet loss possible with Cilium's older mutual-authentication design and encrypting supported TCP traffic between pods on the same node.

This has parallels with Istio's ambient mode, and the Cilium implementation builds on the ztunnel project originally created for Istio. Cilium's ztunnel remains beta, while its older Mutual Authentication feature is now deprecated. Operators considering an upgrade should also consult the 1.20 release notes, which identify possible action for users of legacy Mutual Authentication, Kafka-aware policies, Envoy Go extensions, custom CNI configuration and several deprecated APIs.