Workload-Level Security Without the Service Mesh Tax
Microsoft and Isovalent announced the public preview of Cilium-based mutual TLS encryption for Azure Kubernetes Service this week, offering a middle path between node-level encryption and full service meshes. The feature runs directly in the Azure CNI dataplane—no sidecars required, no application changes needed, and no additional control plane to manage.
This release represents the culmination of a close engineering collaboration between Microsoft and Isovalent, which Cisco acquired in 2024. It brings transparent, workload-level encryption to AKS customers who need cryptographic proof of identity without the operational complexity of traditional service meshes.
The Encryption Dilemma
Kubernetes teams historically faced a binary choice for in-transit encryption:
Node-level encryption using WireGuard, VXLAN, or virtual network encryption secures traffic between nodes but cannot authenticate individual workloads. Any pod on an encrypted node can talk to any other pod. This satisfies compliance requirements for data-in-transit protection but fails to implement zero-trust principles. If an attacker compromises a node, they gain access to all traffic on that node.
Service meshes provide strong identity and mTLS but introduce operational complexity: sidecar resources that increase memory and CPU usage, upgrade coordination across the cluster, configuration sprawl, and debugging challenges when traffic flows break. For many teams, the security benefits do not justify the operational overhead.
Cilium mTLS splits the difference. It delivers workload-level authentication and encryption without a separate control plane or sidecar containers. This is encryption as a dataplane feature, not as an add-on service.
How It Works
The architecture uses three components working together transparently:
Cilium Agent: Runs on each node and enrolls pods in mTLS. When you label a namespace with io.cilium/mtls-enabled=true, the agent enters each pod’s network namespace and installs iptables rules redirecting outbound traffic to a local proxy. It also passes workload metadata—pod IP and namespace context—to the tunnel component.
Ztunnel: A lightweight, per-node Layer 4 proxy originally created by Istio and contributed to the open-source ecosystem. On the source node, Ztunnel 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 hold inline until authentication completes, ensuring traffic is never sent in plaintext.
The destination Ztunnel decrypts traffic and delivers it into the target pod, bypassing interception rules via an in-pod mark. The application sees a normal plaintext connection—completely unaware that encryption occurred.
SPIRE: The SPIFFE Runtime Environment acts as the cluster Certificate Authority, issuing short-lived X.509 certificates called SVIDs that are automatically rotated every hour. Identity derives from Kubernetes namespace and ServiceAccount—not IP addresses. This decouples trust from network topology.
The Trust Model
SPIRE-issued certificates bind identity to Kubernetes namespace and ServiceAccount. This decouples trust from network topology entirely. A pod reschedules, its identity follows. The certificate rotates automatically. Authentication succeeds regardless of which node the pod lands on.
The result is zero-trust networking aligned with Kubernetes RBAC boundaries. Trust decisions align naturally with how Kubernetes already organizes workloads. This enables a zero-trust networking model that fits cleanly into existing AKS security practices without requiring new abstractions.
Traffic Flow
When a pod initiates a TCP connection:
- iptables rules redirect traffic to the local Ztunnel
- 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 traffic and delivers it to the target pod
- Every packet from an enrolled pod is encrypted with no plaintext window
Every packet from an enrolled pod is encrypted. There is no plaintext window and no dropped first packets. The connection holds inline by Ztunnel until the mTLS tunnel is established, then traffic flows bidirectionally through an HBONE (HTTP/2 CONNECT) tunnel.
Opt-In by Namespace
Adoption is gradual and non-breaking. Platform teams enable mTLS by applying a single label to a namespace:
kubectl label namespace production io.cilium/mtls-enabled=trueFrom that point, all pods in the namespace participate in mTLS. Traffic to non-enrolled namespaces continues in plaintext. No connectivity failures. No hard cutovers. This model enables gradual rollout, staged migrations, and low-risk adoption across environments.
Encryption applies only when both pods are enrolled. Traffic between enrolled and non-enrolled workloads continues in plaintext without causing connectivity issues or hard failures.
Prerequisites and Setup
Cilium mTLS requires Azure CNI powered by Cilium and Advanced Container Networking Services enabled. Enable when creating a new cluster or on an existing cluster by updating the Advanced Container Networking Services configuration.
Use Cases
Cilium mTLS fits when you need workload-level encryption for compliance requirements like PCI-DSS, HIPAA, or SOC 2. It works when service mesh overhead exceeds your operational budget and you want encryption without application changes. The gradual migration model supports environments where hard cutovers would be unacceptable.
However, it does not replace service meshes for Layer 7 traffic management including retries, circuit breakers, and timeouts. It does not provide observability requiring HTTP-level visibility. And it does not handle multi-cluster service discovery.
The Bigger Picture
This release reflects a broader trend: eBPF-based networking absorbing security functions previously handled by sidecars or external appliances. Cisco’s acquisition of Isovalent signaled this direction. Microsoft’s integration of that work into AKS confirms it.
For platform teams, it means fewer moving parts. For security teams, it means transparent encryption with cryptographic proof of workload identity. For application teams, it means nothing changes in their code or configuration.