We are thrilled to announce the public preview of Cilium mTLS encryption in Azure Kubernetes Service (AKS), delivered as part of Advanced Container Networking Services and powered by the Azure CNI dataplane built on Cilium.
This capability is the result of a close engineering collaboration between Microsoft and Isovalent (now part of Cisco). It brings transparent, workload‑level mutual TLS (mTLS) to AKS without sidecars, without application changes, and without introducing a separate service mesh stack.
This public preview represents a major step forward in delivering secure, high‑performance, and operationally simple networking for AKS customers. In this post, we’ll walk through how Cilium mTLS works, when to use it, and how to get started.
Why Cilium mTLS encryption matters
Traditionally, teams looking to in-transit traffic encryption in Kubernetes have had two primary options:
- Node-level encryption (for example, WireGuard or virtual network encryption), which secures traffic in transit but lacks workload identity and authentication.
- Service meshes, which provide strong identity and mTLS guarantees but introduce operational complexity.
This trade‑off has become increasingly problematic, as many teams want workload‑level encryption and authentication, but without the cost, overhead, and architectural impact of deploying and operating a full-service mesh.
Cilium mTLS closes this gap directly in the dataplane. It delivers transparent, inline mTLS encryption and authentication for pod‑to‑pod TCP traffic, enforced below the application layer. And implemented natively in the Azure CNI dataplane built on Cilium, so customers gain workload‑level security without introducing a separate service mesh, resulting in a simpler architecture with lower operational overhead.
To see how this works under the hood, the next section breaks down the Cilium mTLS architecture and follows a pod‑to‑pod TCP flow from interception to authentication and encryption.
Architecture and design: How Cilium mTLS works
Cilium mTLS achieves workload‑level authentication and encryption by combining three key components, each responsible for a specific part of the authentication and encryption lifecycle.
Cilium agent: Transparent traffic interception and wiring
Cilium agent which already exists on any cluster running with Azure CNI powered by cilium, is responsible for making mTLS invisible to applications. When a namespace is labelled with “io.cilium/mtls-enabled=true”, The Cilium agent enrolls all pods in that namespace. It enters each pod's network namespace and installs iptables rules that redirect outbound traffic to ztunnel on port 15001.
It is also responsible for passing workload metadata (such as pod IP and namespace context) to ztunnel.
Ztunnel: Node‑level mTLS enforcement
Ztunnel is an open source, lightweight, node‑level Layer 4 proxy that was originally created by Istio. Ztunnel runs as a DaemonSet, on the source node it looks up the destination workload via XDS (streamed from the Cilium agent) and establishes mutually authenticated TLS 1.3 sessions between source and destination nodes. Connections are held inline until authentication is complete, ensuring that traffic is never sent in plaintext.
The destination ztunnel decrypts the traffic and delivers it into the target pod, bypassing the interception rules via an in-pod mark. The application sees a normal plaintext connection — it is completely unaware encryption happened.
SPIRE: Workload identity and trust
SPIRE (SPIFFE Runtime Environment) provides the identity foundation for Cilium mTLS. SPIRE acts as the cluster Certificate Authority, issuing short‑lived X.509 certificates (SVIDs) that are automatically rotated and validated.
This is a key design principle of Cilium mTLS - trust is based on workload identity, not network topology.
Each workload receives a cryptographic identity derived from:
- Kubernetes namespace
- Kubernetes ServiceAccount
These identities are issued and rotated automatically by SPIRE and validated on both sides of every connection. As a result:
- Identity remains stable across pod restarts and rescheduling
- Authentication is decoupled from IP addresses
- Trust decisions align naturally with Kubernetes RBAC and namespace boundaries
This enables a zero‑trust networking model that fits cleanly into existing AKS security practices.
End‑to‑End workflow example
To see how these components work together, consider a simple pod‑to‑pod connection:
- A pod initiates a TCP connection to another pod.
- Traffic intercepted inside the pod network namespace and redirected to the local ztunnel instance.
- ztunnel retrieves the workload identity using certificates issued by SPIRE.
- ztunnel establishes a mutually authenticated TLS session with the destination node’s ztunnel.
- Traffic is encrypted and sent between pods.
- The destination ztunnel decrypts the traffic and delivers it to the target pod.
Every packet from an enrolled pod is encrypted. There is no plaintext window, and no dropped first packets. The connection is held inline by ztunnel until the mTLS tunnel is established, then traffic flows bidirectionally through an HBONE (HTTP/2 CONNECT) tunnel.
Workload enrolment and scope
Cilium mTLS in AKS is opt‑in and scoped at the namespace level.
Platform teams enable mTLS by applying a single label to a namespace. From that point on:
- All pods in that namespace participate in mTLS
- Authentication and encryption are mandatory between enrolled workloads
- Non-enrolled namespaces continue to operate unchanged
Encryption is applied only when both pods are enrolled. Traffic between enrolled and non‑enrolled workloads continues in plaintext without causing connectivity issues or hard failures. This model enables gradual rollout, staged migrations, and low-risk adoption across environments.
Getting started in AKS
Cilium mTLS encryption is available in public preview for AKS clusters that use:
- Azure CNI powered by Cilium
- Advanced Container Networking Services
You can enable mTLS:
- When creating a new cluster, or
- On an existing cluster by updating the Advanced Container Networking Services configuration
Once enabled, enrolling workloads is as simple as labelling a namespace.
👉 Learn more
Looking ahead
This public preview represents an important step forward in simplifying network security for AKS and reflects a deep collaboration between Microsoft and Isovalent to bring open, standards‑based innovation into production‑ready cloud platforms. We’re continuing to work closely with the community to improve the feature and move it toward general availability.
If you’re looking for workload‑level encryption without the overhead of a traditional service mesh, we invite you to try Cilium mTLS in AKS and share your experience.
Microsoft