Cilium 1.20, the second major open source Cilium release of 2026 after Cilium 1.19, is finally here. Three themes stand out in this release:

• Gateway API becomes a much broader traffic management layer. Cilium jumps from Gateway API v1.4 to v1.6 and adds ExternalAuth, CORS filters, ListenerSets, and TCPRoute and UDPRoute for non-HTTP traffic. Platform and security teams can manage more of their north-south traffic through the same API, with authentication and authorization handled before a request reaches the application. If you are still running Ingress NGINX, now is the time to let the CNI you already run take on that traffic management too.
• Cilium becomes a platform that cloud providers can extend. Cilium is already a common networking foundation across hyperscalers and neoclouds. Datapath plugins, developed by Google, make Cilium less like a sealed networking appliance and more like a network operating system: a stable core that cloud providers can extend with their own eBPF programs, independently of the Cilium release cycle.
• Innovation and standardization move forward together. Cilium continues to push the datapath with innovations such as netkit, while aligning more closely with the wider Kubernetes ecosystem through stable MCS API support and Kubernetes ClusterNetworkPolicy. As capabilities Cilium supported early, including multi-cluster services and cluster-wide policy, take shape as upstream Kubernetes APIs, Cilium supports those APIs alongside its own established CRDs. Users get a choice between Cilium-native features and portable Kubernetes resources.
• choice between Cilium-native features and portable Kubernetes resources.

Thank you to every contributor, reviewer and maintainer who made Cilium 1.20 possible, including engineers from Datadog, Google, Microsoft and many other organisations across the Cilium community.

Networking

ENI IPAM mode with IPv6

One of the final gaps that stopped us from claiming feature parity across IPv4 and IPv6 in Cilium is gone. It even makes a footnote in Chapter 4 of Cilium: Up and Running redundant, and while we are a little sad that a note in the book is obsolete so soon after publication, we are glad that ENI mode on AWS finally supports IPv6, four years after the feature request was first raised.

Let’s recap. Up until now, running Cilium in AWS ENI IPAM mode (the AWS-specific mode that gives pods real VPC addresses) was only possible on IPv4. Now, as a beta feature in Cilium 1.20, ENI IPAM can allocate and hand out IPv6 as well. The operator attaches an IPv6 /80 prefix to each node’s ENI through Prefix Delegation (which we covered in detail in an earlier blog on how to overcome IP address exhaustion in Kubernetes), and the agent assigns pod addresses from it.

Enable ENI IPAM and IPv6 together:

ipam:

mode: eni

eni:

enabled: true

ipv6:

enabled: true

Pods on EKS then boot up dual-stack with VPC-routable IPv6:

NAME IPS

dualstack-demo-7f8876746b-5xvnk 192.168.128.71,2a05:d01c:38d:4c02:909e::e771

dualstack-demo-7f8876746b-8lj6z 192.168.177.118,2a05:d01c:38d:4c00:1cf5::57d1

dualstack-demo-7f8876746b-p84p7 192.168.169.190,2a05:d01c:38d:4c00:1cf5::f7ea

And here is the other side of it in the AWS console: the /80 IPv6

prefix delegated to a worker node’s ENI. The IPv6 address from the first pod above comes straight out of this 2a05:d01c:38d:4c02:909e::/80

range.

Kudos to the folks at Datadog, one of the most impactful organizations contributing to Cilium for years now, for building ENI IPv6 support and finally closing that gap. Watch the video for a short demo.

If you’d like to learn more about this feature, check the documentation for more information.

Automatic datapath mode selection (netkit auto)

In our post covering netkit, we described the newer pod network device as “The Final Frontier in Container Networking Performance”. You can call us out on the hyperbole, but since its release, Meta has rolled it out across millions of containers, while ByteDance has been deploying at a similar scale, reporting a 10% performance improvement in its tests.

The TL;DR on netkit is this: it replaces the traditional veth pair and its overhead, bringing pod networking performance to host-level throughput.

When it was initially released in Cilium, it needed a recent kernel (>= 6.8), so on a fleet with mixed kernel versions you either gave up on netkit everywhere or carved your nodes into pools by kernel version and configured them separately.

Cilium 1.20 adds bpf.datapathMode=auto

: each agent probes its own host at startup, uses netkit when the kernel supports it, and quietly falls back to veth

when it does not. That means you only need to configure one setting across a mixed fleet, making netkit easier to adopt across your environment. You can see which mode each node actually landed on through cilium-dbg

status and the cilium_feature_datapath_config metric

:

$ cilium-dbg status | grep Device

Device Mode: netkit [Configured: auto]

$ cilium-dbg metrics list | grep datapath_config

cilium_feature_datapath_config configured_mode=auto operational_mode=netkit 1.000000

While the default stays veth (meaning nothing changes until you opt in), we feel that the days of veth are numbered.

Check the documentation for more info.

Datapath Plugins

Previously, extending or instrumenting Cilium’s eBPF datapath beyond what the project already supported left you with two hard options: upstream your change, or maintain a fork. Both are high-effort, and a fork means carrying datapath patches across every Cilium upgrade.

While most end-users just use the off-the-shelf Cilium, some cloud providers – like Google, the authors of this new feature – would manage their own Cilium fork, with the maintenance efforts it comes up with.

Now, Cilium 1.20 introduces datapath plugins (beta): third-party code can instrument Cilium’s eBPF datapath as its own plugin, running as a separate process that Cilium reaches out to, without patching or forking Cilium itself. Because a plugin is its own image, it is built, versioned and rolled out on its own cadence and can be upgraded independently of Cilium. And because it runs on its own, a plugin crash does not take the agent down with it. It opens the door to specialised observability, security and networking extensions that ship and evolve independently of the Cilium release cycle, with no fork required.

A plugin registers itself with Cilium through a deliberately small CiliumDatapathPlugin

custom resource:

apiVersion: cilium.io/v2alpha1

kind: CiliumDatapathPlugin

metadata:

name: example

spec:

Fail closed if Cilium cannot reach the plugin.

attachmentPolicy: Always

Bump this to reinitialise the datapath for a new plugin release.

version: 0.0.

Thanks to jrife for the feature.

If you’d like to learn more about this feature, check the documentation for more information.

Per-pod disable source IP verification

By default, Cilium enforces source IP verification: a pod may only send packets whose source IP matches its own. This stops a compromised or misbehaving pod from spoofing another workload’s address. There are – admittedly rare – circumstances where some workloads legitimately need to emit packets with a different source IP: for example, NAT gateways, firewalls and other appliance-style pods (such as VPN/Tailscale) .

Until now, source IP verification was a single cluster-wide switch (enable-source-ip-verification

, on by default) with no per-pod control – so letting one workload use a foreign source IP meant turning it off for the entire cluster, weakening anti-spoofing everywhere.

Cilium 1.20 makes it a per-pod, opt-in decision, gated at two levels. First, a cluster administrator permits it for a namespace by annotating the namespace with config.cilium.io/delegate-source-ip-verification

: “true”. Only then can a pod owner opt a specific workload out of source IP verification by annotating it with config.cilium.io/disable-source-ip-verification

: “true”. Both annotations are required, so a namespace owner cannot quietly turn anti-spoofing off on their own, and the protection stays on everywhere else. This feature solves a problem for the workloads that need it, but make sure to use Kubernetes RBAC to restrict who can modify namespace annotations, so you don’t accidentally reduce your security posture.

If you’d like to learn more about this feature, check the documentation for more information.

Migrate cluster-pool IPAM to multi-pool IPAM

Multi-pool IPAM is steadily becoming the preferred way to hand out pod IPs in Cilium. Instead of drawing every address from one flat cluster-wide range, you carve the space into named pools and assign them where you want them – per namespace, per workload, per tenant. What had been difficult until now was the migration from the default cluster scope mode. Until now, if your cluster was already running cluster-scope IPAM, moving to multi-pool meant standing up a fresh cluster and migrating workloads across, which is not something anyone wants to do on a live platform.

Cilium 1.20 adds an in-place migration path. You can switch an existing cluster from cluster-pool

to multi-pool

, with no rebuild and no re-IP’ing, by using the operator option enable-cluster-pool-to-multi-pool-migration

. Check out the migration documentation for more info.

Traffic distribution PreferSameZone / PreferSameNode

Introduced in Cilium 1.16, Service Traffic Distribution became the preferred method for keeping Service traffic close to its client, replacing the older topology-aware hints method. Service Traffic Distribution enables users to reduce latency and avoid cross-zone data-transfer charges, as Dean covered in this excellent post.

Until now, Cilium only supported the PreferClose

value, indicating a preference for routing traffic to endpoints that are topologically proximate to the client.

In Cilium 1.20, Cilium honours recent changes to the upstream Kubernetes trafficDistribution

specification and now supports two newer values. PreferSameZone

keeps traffic within the client’s zone while a healthy backend is available there, and PreferSameNode prefers a backend on the very same node.

apiVersion: v1

kind: Service

metadata:

name: frontend

spec:

trafficDistribution: PreferSameZone

selector:

app: frontend

ports:

• protocol: TCP

port: 80

targetPort: 80

type: ClusterIP

Both values gracefully fall back to the rest of the cluster’s backends when no local one is healthy, so you get the locality benefit without trading away availability. Because this is the standard Kubernetes field rather than a Cilium-specific annotation, the same Service spec behaves consistently across conformant implementations.

Check the official Kubernetes documentation for more information on service traffic distribution.

EndpointSlice weights for Maglev backends

Cilium has supported Maglev as its load balancer hashing mechanism since Cilium 1.10. Originated at Google and named after the Japanese magnetic levitation train, Maglev provides consistent hashing to minimize disruption during node or backend changes (you can find more information about Maglev and other performance optimization features in Chapter 8 of Cilium Up and Running).

In prior releases, there was no supported way to give some backends of a Service a larger share of Maglev traffic than others, or to gracefully drain a group of backends. Traffic was evenly distributed across all available backends.

Now, Cilium 1.20 reads a service.cilium.io/weight annotation directly off the EndpointSlice. The weight applies to every backend in that slice, with valid values running from 0 to 65535 (note the weights are relative, so they do not need to add up to 100). This is aimed squarely at selectorless Services backed by several manually managed EndpointSlice objects, where each slice can carry a different weight: a classic weighted split such as 70/30 across two slices becomes a two line annotation change.

apiVersion: v1

kind: Service

metadata:

name: example-service

annotations:

service.cilium.io/lb-algorithm: maglev

spec:

type: ClusterIP

ports:

• name: http

port: 8080

protocol: TCP

targetPort: 8080

no selector: endpoints come from the manual EndpointSlices below

---

apiVersion: discovery.k8s.io/v1

kind: EndpointSlice

metadata:

name: example-service-1

labels:

kubernetes.io/service-name: example-service

annotations:

service.cilium.io/weight: "70" # applies to every backend in this slice

addressType: IPv4

ports:

• name: http

protocol: TCP

port: 8080

endpoints:

• addresses: ["10.0.0.11"]
• addresses: ["10.0.0.12"]

---

apiVersion: discovery.k8s.io/v1

kind: EndpointSlice

metadata:

name: example-service-2

labels:

kubernetes.io/service-name: example-service

annotations:

service.cilium.io/weight: "30" # set to "0" to drain these backends

addressType: IPv4

ports:

• name: http

protocol: TCP

port: 8080

endpoints:

• addresses: ["10.0.0.21"]
• addresses: ["10.0.0.22"]

The special case is a weight of 0. Instead of removing the backends, it marks them as being in maintenance: existing connections continue to work, but the backends leave the Maglev lookup table so no new connections are steered to them. That gives you a clean, connection-preserving drain, which is exactly what you want when taking a group of backends out of rotation for maintenance. Invalid values are ignored and fall back to the default behaviour, so a typo never takes a Service down.

Cilium 1.19 introduced support for Gateway API v1.4. Cilium 1.20 moves from Gateway API v1.4 to v1.6 and implements several of the capabilities that graduated across those releases.

From v1.5, TLSRoute (a feature Cilium introduced back in 1.14), the HTTPRoute CORS filter and ListenerSets all reached the Standard channel as generally available, and Gateway (and HTTPRoute) level authentication landed as an experimental feature. From v1.6, TCPRoute and UDPRoute graduated to Standard as well.

Gateway API continues to be a thriving project. Its accelerated development is a boon to anyone looking at migrating off Ingress – and its most popular implementation, Ingress NGINX – and Cilium keeps up with its pace.

Gateway API ExternalAuth filter

Cilium’s security features have always stood out. Built-in traffic encryption within or between meshed clusters, network policy for cluster segmentation, mutual TLS (now with zTunnel, which we cover later) provide a compelling set of security capabilities. One gap remained at the north/south boundary: authenticating users, scripts, and agents arriving from outside wasn’t easy to accomplish natively and, in prior releases, required customizing Cilium’s built-in Envoy proxy.

Cilium 1.20 closes that gap, by supporting the ExternalAuth filter in Gateway API (GEP-1494).

The idea is simple. You attach the filter to an HTTPRoute, and for every matching request the gateway checks with an external authorization service before forwarding any traffic. If the caller hasn’t authenticated yet, the authorizer sends them through an authentication flow first – a 302

redirect to a login page for a human in a browser, or a 401 / 403

for a request that presents no valid credentials. Only once the caller has authenticated and the authorizer returns 200 OK

does the gateway forward the request to your backend. On the way through, the authorizer can also inject identity headers (who the caller is and which groups they belong to) so your application makes the final authorization call without ever touching a password or a token.

The feature applies to very different callers on the same gateway. A human hitting the dashboard in a browser gets redirected to an SSO provider (such as Authelia or Duo) and comes back with a session cookie. A CI job or script presents a JWT that oauth2-proxy validates against an identity provider (such as Keycloak, Duo or Okta). And an AI agent talking MCP authenticates with a service-account client, with no interactive login at all.

The filter sits directly on the HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: hr-dashboard

spec:

parentRefs:

• name: acme-gateway

rules:

• matches:
• path:

type: PathPrefix

value: /

filters:

• type: ExternalAuth

externalAuth:

protocol: HTTP

backendRef:

name: authelia

port: 80

http:

path: /api/authz/ext-authz

allowedHeaders:

• cookie

allowedResponseHeaders:

• Remote-User
• Remote-Email
• Remote-Name
• Remote-Groups

backendRefs:

• name: hr-dashboard

port: 8080

The authorizer’s response determines what the gateway does:

200:

forward the request to the backend.302:

redirect the caller, for example to an SSO login page.401 or 403:

block the request at the gateway.

If you’d like to learn more, check out our External Auth lab!

Gateway API TCPRoute and UDPRoute support

Ever since Gateway API arrived in the 1.13 release, Cilium has kept in lockstep with every Gateway API release, adding TLS termination, TLS Passthrough, GRPCRoute, GAMMA (for east-west use cases) and many more features along the way.

Cilium 1.20 carries on in this vein. On top of the ExternalAuth feature mentioned above, a big addition to Cilium’s Gateway API support is TCPRoute and UDPRoute. Prior to this release, to expose a plain TCP or UDP service (a database, a DNS server, a game server) you had to drop out of the Gateway API model and back to raw LoadBalancer or NodePort Services. With TCPRoute and UDPRoute support, you can now manage L4 services through the same Gateway API you already use for HTTP or gRPC.

UDPRoute is ideal for applications such as DNS, VoIP, gaming, streaming media, IoT and telemetry (GEP-2645), while TCPRoute is handy for databases, message brokers, mail protocols and other TCP-based services (GEP-2644).

You can attach HTTP, TCP and UDP routes to a single shared Gateway:

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: demo-gateway

namespace: default

spec:

gatewayClassName: cilium

listeners:

• name: web

protocol: HTTP

port: 80

allowedRoutes:

kinds:

• kind: HTTPRoute
• name: mongo

protocol: TCP

port: 27017

allowedRoutes:

kinds:

• kind: TCPRoute
• name: dns

protocol: UDP

port: 53

allowedRoutes:

kinds:

• kind: UDPRoute

In this example, an HTTPRoute serves Dean’s eBee Pac-Man app, a TCPRoute connects to the MongoDB database holding its high scores, and a UDPRoute sends DNS queries to CoreDNS:

apiVersion: gateway.networking.k8s.io/v1

kind: TCPRoute

metadata:

name: mongo

namespace: default

spec:

parentRefs:

• name: demo-gateway

sectionName: mongo

rules:

• backendRefs:
• name: pacman-mongo

port: 27017

---

apiVersion: gateway.networking.k8s.io/v1

kind: UDPRoute

metadata:

name: dns

namespace: default

spec:

parentRefs:

• name: demo-gateway

sectionName: dns

rules:

• backendRefs:
• name: coredns

port: 53

Each backend is reachable through the same Gateway address (172.18.255.200

) on its own port. After playing a round of eBee Pac-Man over the HTTPRoute, the score lands in MongoDB and can be read back over the TCPRoute:

$ mongosh mongodb://172.18.255.200:27017/pacman --quiet \

--eval 'db.highscore.find({}, {_id:0, name:1, score:1, level:1}).sort({score:-1})'

[ { name: 'Nico', score: 400, level: 1 } ]

CoreDNS is available over the UDPRoute:

$ dig @172.18.255.200 -p 53 ebeepacman.cilium.rocks

; <<>> DiG 9.20.23 <<>> @172.18.255.200 -p 53 ebeepacman.cilium.rocks

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15177

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;ebeepacman.cilium.rocks. IN A

;; ANSWER SECTION:

ebeepacman.cilium.rocks. 3600 IN A 192.0.2.42

;; Query time: 1 msec

;; SERVER: 172.18.255.200#53(172.18.255.200) (UDP)

Thanks to external contributor eminaktas for landing this long-standing request.

Gateway API ListenerSets

Shared Gateways create an awkward ownership problem: the platform team controls the Gateway object, but application teams own the endpoints behind it. Adding another hostname or port therefore requires someone with write access to modify that central resource, creating a potential bottleneck in multi-tenant clusters. Without a delegation mechanism, this risks reproducing the same centralized configuration problem found in the inflexible Ingress API, one of the limitations Gateway API was designed to address.

Cilium 1.20 implements Gateway API ListenerSets, allowing application teams to attach and manage additional Listeners from their own namespaces. These Listeners share the parent Gateway’s address and infrastructure, while the platform team retains ownership of the Gateway and controls which namespaces may extend it. The result is a clean delegation model with per-namespace ownership and correct hostname filtering for attached routes.

The following manifests show this delegation in practice: a platform-owned Gateway authorizes a labelled application namespace to add its own Listener, while an HTTPRoute in that namespace attaches directly to the delegated Listener.

---

apiVersion: v1

kind: Namespace

metadata:

name: listenerset-demo

labels:

gateway-access: "true"

---

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

name: shared-gateway

namespace: default

spec:

gatewayClassName: cilium

allowedListeners:

namespaces:

from: Selector

selector:

matchLabels:

gateway-access: "true"

listeners:

• name: base-http

protocol: HTTP

port: 8081

---

apiVersion: gateway.networking.k8s.io/v1

kind: ListenerSet

metadata:

name: delegated-listeners

namespace: listenerset-demo

spec:

parentRef:

name: shared-gateway

namespace: default

listeners:

• name: echo

hostname: echo.example.com

protocol: HTTP

port: 80

---

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: echo

namespace: listenerset-demo

spec:

parentRefs:

• group: gateway.networking.k8s.io

kind: ListenerSet

name: delegated-listeners

sectionName: echo

hostnames:

• echo.example.com

rules:

• backendRefs:
• name: echo-1

port: 8080

For more details on ListenerSet, check the documentation for more information.

More Gateway API improvements

Alongside the move from Gateway API v1.4 to v1.6, Cilium 1.20 fills in several smaller but useful gaps in its HTTP traffic handling.

Cilium now supports the Gateway API CORS filter natively. You can declare allowed origins, methods and headers, exposed response headers, credential handling and cache duration directly on the route.

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

name: echo-cors

namespace: default

spec:

parentRefs:

• name: cors-gateway

rules:

• filters:
• type: CORS

cors:

allowOrigins:

• "https://www.foo.com"
• "https://*.bar.com"

allowMethods:

• GET
• OPTIONS

allowHeaders:

• "x-custom-header"

exposeHeaders:

• "x-response-header"

allowCredentials: true

maxAge: 3600

backendRefs:

• name: echo-1

port: 8080

Redirect handling is more complete too. In addition to 301 and 302 redirect codes we covered in the deep dive tutorial on “Redirect, Rewrite, and Mirror HTTP with Cilium Gateway API”, Cilium now formally supports and tests the optional 303, 307 and 308 HTTPRoute redirect codes. This gives users more precise control over whether a redirect is temporary or permanent and whether the original HTTP method and body should be preserved. You can try out redirection in the Advanced Gateway API Use Cases lab.

Finally, CiliumGatewayClassConfig can now control the HTTP Server response header. Its OVERWRITE

, APPEND_IF_ABSENT

and PASS_THROUGH

modes let operators replace the header, add one only when the backend has not supplied it, or preserve the backend value. This is useful for applying a consistent value or preventing backend implementation details from being exposed.

Security

ztunnel: sidecarless mTLS service mesh

Cilium 1.19 introduced ztunnel, a purpose-built per-node proxy that brings sidecarless mutual TLS to pod-to-pod traffic, and Cilium 1.20 keeps that work moving.

The longer-term direction is for ztunnel to supersede Cilium’s original mutual authentication feature, which has been Beta since 1.14. That feature intentionally separated authentication from encryption. Cilium agents performed an out-of-band mTLS handshake to authenticate each new identity pair, while Cilium’s existing IPsec or WireGuard transparent encryption protected the workload traffic. This allowed mutual authentication to build on encryption capabilities Cilium already provided. One consequence of this design was that the first packet could be dropped while the authentication handshake completed. In addition, because transparent encryption operates between nodes, traffic between pods on the same node was not encrypted.

ztunnel takes a different approach by providing authentication and encryption together in the traffic path. Once you enroll a namespace by applying the io.cilium/mtls-enabled=true label

, ztunnel holds each new connection while it establishes an mTLS session using TLS 1.3 over an HBONE (HTTP-Based Overlay Network Environment) tunnel. This avoids the first-packet drop and encrypts every supported TCP flow between enrolled pods, including pods running on the same node.

ztunnel remains Beta, but Cilium 1.20 improves its operational readiness. The certificate authority is now configurable: the default internal

mode runs ztunnel mTLS without requiring SPIRE, while spire

mode uses SPIFFE workload identities, with SPIRE issuing and rotating certificates for teams that want the CNCF-graduated SPIFFE and SPIRE identity stack. There are also new Prometheus metrics for enrollment and connection health. The dashboard below combines those metrics with Kubernetes workload data to show protected workloads, enrollment activity, failures and the connection state of each node’s ztunnel.

These improvements continue the joint engineering effort between Microsoft and Isovalent and build on the upstream ztunnel project, originally created for Istio’s ambient mesh.

As ztunnel matures, it is becoming the clear successor to the original mutual authentication feature. In Cilium 1.20, the maintainers marked legacy Mutual Authentication as deprecated, with removal planned for a later release.

Ztunnel support in Cilium remains currently in Beta. Make sure to review the documentation for current limitations and configuration guidance before rolling this out in production. For more information, see the blog and the ztunnel introduction in the Cilium 1.19 release blog.

Kubernetes ClusterNetworkPolicy (KCNP) support

A Kubernetes NetworkPolicy (KNP) is namespaced and additive: it is written by application teams, and there is no native way for a cluster administrator to set a rule that applies cluster-wide or that takes precedence over what a namespace owner writes. The upstream network-policy-api subgroup has been working on filling that gap, and its latest iteration consolidates the earlier AdminNetworkPolicy and BaselineAdminNetworkPolicy into a single ClusterNetworkPolicy.

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.

A policy selects a subject (by namespace or pod), sets a priority, and lists ingress/egress rules with an action of Accept

, Deny

or Pass

. Those selectors accept matchExpressions

in addition to matchLabels

so you can target sets of namespaces or pods with set-based rules like In, NotIn and Exists. This gives platform teams the guardrails they have wanted: enforce a cluster-wide baseline, or hard-deny some traffic that no namespace can re-open.

For example, an Admin-tier policy can deny all ingress to a selected namespace:

apiVersion: policy.networking.k8s.io/v1alpha2

kind: ClusterNetworkPolicy

metadata:

name: deny-to-server

spec:

tier: Admin

priority: 10

subject:

namespaces:

matchLabels:

kubernetes.io/metadata.name: kcnp-server

ingress:

• name: deny-all

action: Deny

from:

• namespaces: {}

For users who prefer using upstream APIs like KNP and KCNP rather than Cilium-specific Cilium Network Policies and ClusterWide Cilium Network Policies, this is a welcome addition to your segmentation toolkit.

If you’d like to learn more about this feature, check the documentation for more information.

New cluster-mesh policy entity & policy map aggregation

In previous Cilium versions, allowing traffic from “anywhere in my Cluster Mesh” in Cilium Network Policies meant either enumerating remote clusters by name or falling back to label selectors that spanned the mesh, since the cluster entity

only covered the local cluster. Such policy was verbose to write, easy to get wrong as clusters came and went, and costly at scale because each remote identity consumed its own BPF policy-map entry.

Now, Cilium 1.20 adds a cluster-mesh policy entity that selects every endpoint in every meshed cluster in a single word. You write fromEntities: cluster-mesh

once and it keeps matching as clusters join or leave the mesh. Underneath, both cluster

and cluster-mesh

now aggregate their identities into far fewer policy-map entries, so the mesh-wide rule is also the cheaper one to enforce at scale.

The policy is as simple as using the new entity in fromEntities

:

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

name: backend-ingress

spec:

endpointSelector:

matchLabels:

app: backend

ingress:

• fromEntities:
• cluster-mesh

The diagrams below illustrate the changes:

If you’d like to learn more about this feature, check the documentation for more information.

Hubble policy correlation for audit verdicts

Previously, when a flow was dropped by a default-deny (nothing matched it) or logged under Policy Audit Mode, Hubble showed the drop but left the policy fields empty. You could see that a flow was denied, but not which policy, or the absence of one, was responsible. That gap made audit mode harder to trust: the whole point of audit mode is to preview what a policy would block before you enforce it, but the verdict did not tell you what would have caught the flow.

Now, in Cilium 1.20, Hubble correlates policy for audit verdicts. Audit flows (Verdict_AUDIT

) populate the ingress_allowed_by / egress_allowed_by

and ingress_denied_by / egress_denied_by fields

, so you can see exactly what would have denied the flow before you flip enforcement on.

For example, given this ingress deny policy:

Explicitly deny alliance ships to the deathstar.

apiVersion: "cilium.io/v2"

kind: CiliumNetworkPolicy

metadata:

name: "deny-alliance"

spec:

endpointSelector:

matchLabels: {class: deathstar}

ingressDeny:

• fromEndpoints:
• matchLabels: {org: alliance}

When xwing with label alliance tries to curl deathstar, an audited flow now names the policy that would have denied it on ingress:

$ hubble observe --type policy-verdict --verdict AUDIT

--print-policy-names

Jul 15 10:11:40.451: default/xwing:40218 (ID:41050) ->

default/deathstar:80 (ID:11009) \

policy-verdict:L3-Only INGRESS AUDITED BY deny-alliance (CiliumNetworkPolicy) (TCP Flags: SYN)

Here is an example of a correlation flow log for a packet allowed on egress, with the corresponding network policy:

apiVersion: "cilium.io/v2"

kind: CiliumNetworkPolicy

metadata:

name: "xwing-egress"

spec:

endpointSelector:

matchLabels: {org: alliance, class: xwing}

egress:

• toEndpoints:
• matchLabels: {class: deathstar}

toPorts:

• ports: [{port: "80", protocol: TCP}]
• toEndpoints:
• matchLabels:

io.kubernetes.pod.namespace: kube-system

k8s-app: kube-dns

toPorts:

• ports: [{port: "53", protocol: UDP}]

$ hubble observe --type policy-verdict --verdict FORWARDED

--print-policy-names

Jul 15 10:11:40.449: default/xwing:40218 (ID:41050) ->

default/deathstar:80 (ID:11009) \

policy-verdict:L3-L4 EGRESS ALLOWED BY xwing-egress

(CiliumNetworkPolicy) (TCP Flags: SYN)

Thanks to Rajneesh180 for the contribution.

Day 2 Operations & Scale

MCS-API reaches stable support in ClusterMesh

Cilium Cluster Mesh provides cross-cluster service discovery and load balancing across up to 255 clusters by default, with built-in support for network policy (as highlighted earlier), observability and service affinity.ia Placeholder

While Cluster Mesh is a popular Cilium feature, it is coupled tightly with Cilium. not portable and vendor-neutral. The Kubernetes SIG multi-cluster working group drove the creation of the portable and vendor-neutral Multi-Cluster Services API standard. Cilium introduced beta MCS-API support a few releases ago and in 1.20, promoted its MCS-API implementation to a stable support level.

The MCS-API provides a standard way to make a Service discoverable across multiple clusters. Imagine that an application runs in two clusters called site-a and site-b, behind a Service named web in the default namespace. Normally, each Service is visible only inside its own cluster. To make web available across the mesh, you create a ServiceExport

with the same name and namespace in both clusters. That is the only additional resource the application team needs to manage.

apiVersion: multicluster.x-k8s.io/v1beta1

kind: ServiceExport

metadata:

name: web

namespace: default

Cilium then combines the exported Services and their backends into a single multi-cluster Service. Workloads in any connected cluster can reach it through the standard MCS-API DNS name web.default.svc.clusterset.local

. Because this naming convention and the ServiceExport

resource are part of the Kubernetes MCS-API, the same application manifests can be used with any conformant implementation.

Under the hood, the Cilium operator creates the corresponding ServiceImport

, allocates the clusterset virtual IP and reconciles the derived Kubernetes Service used to connect to backends across the mesh. Cilium 1.20 moves this implementation to the multicluster.x-k8s.io/v1beta1

CRDs and installs the required CRDs automatically.

Of course, Cilium Global Services remain available, but you now also have a stable, supported alternative for cross-cluster service discovery that uses a portable, standard Kubernetes API.

Thanks to Arthur Outhenin-Chalandre (@MrFreezeex) from Ledger, who authored both the move to the v1beta1 API and the work to promote Cilium’s MCS-API support to stable.

If you’d like to learn more about this feature, check the documentation for more information.

Shrink cilium-cni binary by 80%

Every Cilium agent ships the cilium-cni

plugin and installs it onto the node at /opt/cni/bin/cilium-cni

by default, where the kubelet calls it to wire up each pod. Over time what was originally a small binary had grown: the CNI plugin was pulling in large chunks of the agent codebase through Go imports, and by 1.19 it weighed 76 MB. In 1.20, the plugin is no longer importing packages it never needs and the same binary is 16 MB, resulting in a 79% cut.

In a 1.19 cluster

root@cilium-119-worker:/# ls -la /opt/cni/bin/cilium-cni

-rwxr-xr-x 1 root root 76625528 Jun 16 12:06 /opt/cni/bin/cilium-cni

In a 1.20 cluster

root@cilium-120-worker:/# ls -la /opt/cni/bin/cilium-cni

-rwxr-xr-x 1 root root 16210104 Jul 17 08:59 /opt/cni/bin/cilium-cni

A smaller binary on every node means a smaller image layer to pull and less to copy during each CNI install.

remote-node / world policy identity aggregation

In previous Cilium versions, a policy that selected a broad entity like world or remote-node

expanded, under the hood, into one entry per matching identity in the BPF policy map. On a large or heavily meshed cluster that could mean thousands of entries for a single rule, and in the worst case the policy map could fill up.

Now, Cilium 1.20 teaches the policy map a new kind of wildcard for exactly these semantic groups. Selecting world or remote-node now inserts a single aggregated wildcard entry instead of one entry per matching identity, and the datapath does an extra wildcard lookup to match. The verdict is identical, but the footprint collapses from thousands of entries to a handful, so policy enforcement stays cheap as the cluster and the mesh grow.

BGP Tooling Improvements

Cilium’s BGP support is commonly used in self-managed Kubernetes clusters, to interconnect with an existing network fabric. Cilium BGP relies on the GoBGP platform, a robust and mature Go-based implementation of BGP. In previous versions, debugging a Cilium BGP session from the agent was sometimes challenging: the on-agent BGP commands gave limited output, and there was no way to see which route policies were actually being applied to the speaker.

Cilium 1.20 improves the on-agent BGP tooling, now surfaced through the hive-shell from inside the Cilium agent (cilium-dbg shell -- bgp/...

). A brand-new bgp/route-policies

command shows the route policies Cilium has actually programmed into GoBGP – something you previously had no way to inspect.

$ cilium-dbg shell -- bgp/route-policies

Instance Policy Name Type Statement Name Match Peers Match Families Match Prefixes (Min..Max Len) RIB Action

64513 allow-local import accept-local accept

peer-frr-export export PodCIDR-ipv4 172.18.0.5 10.0.0.0/24 (24..24) accept

In addition, bgp/peers gains a --format

option (table, JSON or detailed); providing a detailed view of per-peer timers, negotiated capabilities and graceful-restart

state.

$ cilium-dbg shell -- bgp/peers --format detailed

Instance: 64513

Peer: frr

Address: 172.18.0.5

PeerAsn: 64512

LocalAsn: 64513

Session State: established

Uptime: 12m10s

Address Families:

ipv4/unicast:

Received Routes: 0

Advertised Routes: 1

Timers:

Hold Time: { Configured: 1m30s, Applied: 1m30s }

Keep Alive Time:{ Configured: 30s, Applied: 30s }

Local Capabilities: multiprotocol (ipv4-unicast), route-refresh, extended-message, 4-octet-as

Remote Capabilities: multiprotocol (ipv4-unicast), route-refresh, extended-message

Heads-up worth calling out: the on-agent cilium-dbg bgp

subcommands and the local REST BGP API

are deprecated in 1.20. Move to the hive-shell equivalents – cilium-dbg shell

-- bgp/peers

, bgp/routes

, bgp/route-policies

. The user-facing cilium bgp CLI is unchanged.

Conclusion

Cilium 1.20 is the product of a community that continues to grow well beyond the code itself. Asana, Etraveli, Michelin, OpenAI, Suse, Telefónica’s acens, and Zynga have all shared stories about running Cilium in production. If your organization has a story to tell, we would love to hear it.

The community also gathered at CiliumCon and the Cilium Developer Summit in Amsterdam, with the CiliumCon talks now available to watch online. The next opportunity to meet in person will be at KubeCon + CloudNativeCon North America in Salt Lake City, where CiliumCon and another Developer Summit will take place from November 9 to 12. We look forward to seeing you there!