Cilium 1.20: ExternalAuth, TCPRoute, and eBPF Datapath Plugins

Cilium 1.20 landed September 14 with 2,660 new commits and a jump from Gateway API v1.4 to v1.6 — and the gap between those two version numbers contains things platform teams have been waiting for. ExternalAuth, TCPRoute, UDPRoute, and eBPF datapath plugins all ship in this release. Here is what each one means and which to act on first.

Auth at the Gateway, Not Inside Your App

The biggest practical win in 1.20 is ExternalAuth for HTTPRoute. The idea is simple: validate requests at the gateway layer before they reach your backend, using an external auth service — OAuth2 proxy, OPA, or anything that speaks Envoy’s ext_authz protocol over HTTP or gRPC.

The problem it solves is real. In a microservices cluster without centralized gateway auth, each service implements its own token validation middleware. One team uses a well-tested library, another ships a custom decorator, a third gets it almost right. ExternalAuth eliminates that sprawl by handling auth once, at the edge, without touching application code.

Here is what a route with ExternalAuth looks like:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-with-auth
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - filters:
    - type: ExtensionRef
      extensionRef:
        group: gateway.cilium.io
        kind: ExternalAuth
        name: oauth2-proxy-auth
    backendRefs:
    - name: my-api
      port: 8080

Platform teams can now enforce cluster-wide authentication policies without asking application teams to change their code. That is the kind of change that gets approved quickly in a security review.

TCPRoute and UDPRoute Close the L4 Gap

Until 1.20, Cilium’s Gateway API implementation was effectively HTTP-only. Teams running databases, message brokers, or DNS servers on Kubernetes had to route them with NodePort services or raw LoadBalancer resources — separate tooling, separate configs, separate mental model.

With TCPRoute and UDPRoute now supported, the Gateway API is a unified routing layer for all protocol traffic:

• TCPRoute: MySQL, PostgreSQL, Redis, Kafka, custom binary protocols
• UDPRoute: DNS authoritative servers, VoIP, game servers, IoT telemetry

The implementation is efficient: TCPRoute and UDPRoute traffic bypasses Envoy entirely and is programmed natively by the Cilium agent. No proxy overhead for L4. The operator resolves listener configuration and passes it directly to the agent, which sets up services at the kernel level.

The practical benefit is consolidation. One Gateway API spec covers your HTTP microservices, your PostgreSQL replica, and your internal DNS forwarder. That simplifies auditing, policy application, and onboarding.

eBPF Datapath Plugins: From Appliance to Platform

The most architecturally significant feature in 1.20 is the least immediately visible: eBPF datapath plugins. Previously, extending Cilium’s eBPF datapath — to add custom observability, DLP inspection, or proprietary security logic — meant either upstreaming your changes or maintaining a fork. Google was doing the latter, carrying datapath patches across every Cilium upgrade. That is what motivated this feature.

Datapath plugins let third-party code instrument Cilium’s eBPF datapath without forking. The plugin runs as its own separate process: Cilium reaches out to it, the plugin does its work, and if the plugin crashes, the Cilium agent keeps running. Independent versioning means a vendor can ship plugin updates without waiting for a Cilium release cycle.

This shifts Cilium from a sealed networking appliance to something closer to a network operating system. Cloud providers building managed Kubernetes platforms can add proprietary extensions. Observability vendors can hook into eBPF-level packet processing without maintaining a fork. That ecosystem dynamic will compound as more vendors adopt the plugin API — and with Google already shipping it, the precedent is set.

Cluster-Wide Policy Tiers with ClusterNetworkPolicy

Cilium 1.20 adds support for the upstream ClusterNetworkPolicy API, which introduces cluster-scoped policy tiers alongside the existing namespace-scoped NetworkPolicy:

• Admin tier: Platform team policies that override whatever namespaces define. Block egress to external IPs, enforce encryption — namespace owners cannot bypass this.
• Baseline tier: Defaults that tenant namespaces can override. Good for “allow monitoring scrape” rules that teams can tighten if needed.

To enable it, set k8sClusterNetworkPolicy.enabled=true in your Helm values and install the CRD from sigs.k8s.io/network-policy-api. It is opt-in, so existing policy configs are unaffected.

What to Do With 1.20

For teams running Cilium 1.19, upgrading to 1.20 is a standard Helm chart update — no breaking changes in core networking. The features worth enabling immediately depend on your use case:

• Set bpf.datapathMode=auto on new nodes (use per-node config or cordon+drain for existing ones) to get netkit on supported kernels automatically
• Enable KCNP if you need cluster-scoped policy enforcement across namespaces
• ExternalAuth and TCPRoute/UDPRoute are available as soon as you update the Gateway API CRDs to v1.6

The full release notes are at the Cilium 1.20.0 GitHub release and the CNCF announcement. The Cilium Gateway API docs cover ExternalAuth configuration in detail. If you are on AKS, the Azure CNI Powered by Cilium documentation has managed upgrade considerations specific to that environment.