AKS Gets Transparent mTLS Encryption Without Service Mesh Overhead

Microsoft has launched public preview of Cilium mTLS encryption for Azure Kubernetes Service (AKS), delivering workload-level mutual TLS encryption without the operational complexity of traditional service meshes. This capability, developed through close collaboration between Microsoft and Isovalent (now part of Cisco), is available as part of Advanced Container Networking Services and powered by the Azure CNI dataplane built on Cilium.

The Security Trade-off That Plagues Kubernetes Teams

Historically, teams seeking to encrypt in-transit traffic in Kubernetes faced an uncomfortable choice. Node-level encryption solutions like WireGuard or virtual network encryption secure traffic at the network layer but lack workload identity and authentication capabilities. Service meshes provide strong identity and mTLS guarantees but introduce significant operational overhead, performance costs, and architectural complexity.

Cilium mTLS directly addresses this gap by delivering transparent, inline mTLS encryption and authentication for pod-to-pod TCP traffic, enforced below the application layer. The solution is implemented natively in the Azure CNI dataplane built on Cilium, allowing customers to gain workload-level security without introducing a separate service mesh stack.

How It Works: The Three-Layer Architecture The Cilium mTLS implementation combines three key components, each handling a specific part of the authentication and encryption lifecycle:

• Cilium agent: Already present on clusters running Azure CNI powered by Cilium, it makes mTLS invisible to applications. When a namespace is labeled with "io.cilium/mtls-enabled=true", the agent enrolls all pods in that namespace, installs iptables rules to redirect outbound traffic to ztunnel on port 15001, and passes workload metadata to ztunnel.

• Ztunnel: An open-source, lightweight, node-level Layer 4 proxy originally created by Istio. Running as a DaemonSet, ztunnel on the source node 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 completes, ensuring traffic never travels in plaintext.

• SPIRE: The SPIFFE Runtime Environment provides the identity foundation for Cilium mTLS. Acting as the cluster Certificate Authority, SPIRE issues short-lived X.509 certificates (SVIDs) that are automatically rotated and validated.

Trust Without Network Topology

This architecture embodies a key design principle: trust is based on workload identity rather than network topology. Each workload receives a cryptographic identity derived from its Kubernetes namespace and ServiceAccount. These identities are issued and rotated automatically by SPIRE and validated on both sides of every connection.

The result is a zero-trust networking model that aligns naturally with Kubernetes RBAC and namespace boundaries. Identity remains stable across pod restarts and rescheduling, authentication is decoupled from IP addresses, and trust decisions integrate cleanly with existing AKS security practices.

End-to-End Workflow

A typical pod-to-pod connection demonstrates the seamless nature of the implementation:

1. A pod initiates a TCP connection to another pod
2. Traffic is intercepted inside the pod's network namespace and redirected to the local ztunnel instance
3. Ztunnel retrieves the workload identity using certificates issued by SPIRE
4. Ztunnel establishes a mutually authenticated TLS session with the destination node's ztunnel
5. Traffic is encrypted and sent between pods
6. The destination ztunnel decrypts the traffic and delivers it to the target pod

The application sees a normal plaintext connection and remains completely unaware that encryption occurred. Every packet from an enrolled pod is encrypted with 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.

Gradual Rollout and Operational Simplicity

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 The public preview is available for AKS clusters using Azure CNI powered by Cilium with Advanced Container Networking Services. Teams can enable mTLS either when creating a new cluster or by updating the Advanced Container Networking Services configuration on an existing cluster. Once enabled, enrolling workloads is as simple as labeling a namespace.

Microsoft provides comprehensive documentation including conceptual overviews of how Cilium mTLS works, its architecture, and trust boundaries, along with step-by-step guides for enabling and verifying mTLS in AKS.

The Future of Kubernetes Security

This public preview represents a significant step forward in simplifying network security for AKS and reflects the deep collaboration between Microsoft and Isovalent to bring open, standards-based innovation into production-ready cloud platforms. The companies continue working closely with the community to improve the feature and move it toward general availability.

For teams seeking workload-level encryption without the overhead of a traditional service mesh, Cilium mTLS offers a compelling alternative that delivers enterprise-grade security with operational simplicity. The solution demonstrates how modern Kubernetes networking can provide sophisticated security capabilities while maintaining the developer experience and operational efficiency that make cloud-native architectures successful.

The implementation showcases how standards-based, open-source technologies can be integrated into cloud platforms to deliver advanced capabilities without vendor lock-in or proprietary complexity. As organizations continue to adopt zero-trust architectures and seek to minimize their attack surface, solutions like Cilium mTLS that provide transparent security at the dataplane level will likely become increasingly important components of cloud-native security strategies.