Encrypting internal traffic and enforcing mutual (mTLS), a form of TLS in which both the client and server authenticate each other using X.509 certificates., has transitioned from a “nice-to-have” to a hard requirement, especially in Kubernetes environments where everything can talk to everything else by default. Whether your objectives are regulatory compliance, or simply aligning to the principles of Zero Trust, the goal is the same: to ensure every connection is encrypted, authenticated, and authorized.
Delivering Cluster-Wide mTLS Without Sidecars
The word ‘service mesh’ is bandied about as the ideal solution for implementing zero-trust security but it comes at a price often too high for organizations to accept. In addition to a steep learning curve, deploying a service mesh with a sidecar proxy in every pod scales poorly, driving up CPU and memory consumption and creating ongoing maintenance challenges for cluster operators.
Istio Ambient Mode addresses these pain points by decoupling the mesh from the application and splitting the service mesh into two distinct layers: mTLS and L7 traffic management, neither of which needs to run as a sidecar on a pod. By separating these domains, Istio allows platform engineers to implement mTLS cluster-wide without the complexity of L7 processing for every single connection. Ambient Mode recognizes that mTLS is a foundational infrastructure requirement, while L7 traffic management is a specific application requirement. With this separation, Istio moves mTLS to the ztunnel, making encryption a transparent part of the platform.
In this context, this post explores how Istio Ambient Mesh delivers mTLS as a platform capability without sidecars using ztunnel, and how this approach fits into a broader zero trust strategy when combined with Calico network policy.
Next, we’ll focus on ztunnel and how it secures pod to pod traffic with mTLS.
What is ztunnel?
ztunnel is a lightweight, node-level proxy that focuses on two responsibilities:
- Encrypting traffic using mTLS
- Managing workload identity
It runs as a DaemonSet, with one instance per node, and is shared by all workloads on that node that participate in the mesh. By moving these responsibilities out of individual pods and into a shared infrastructure component, ztunnel decouples mTLS from the application lifecycle. Pods do not need to be restarted to enable encryption, and application teams do not need to be aware that a mesh is present at all.
Joining Workloads to the Mesh
This model is designed to make adopting mTLS an operational decision for platform teams, rather than a deployment-time concern for application teams. Previously, each workload needed a sidecar to join the mesh. Now, with Ambient Mesh, workloads are added simply by labeling them, without injecting any sidecars. For example, labeling a namespace enables Ambient Mode for all pods in that namespace:
kubectl label namespace istio.io/dataplane-mode=ambient
When a pod is labeled for Ambient Mode, the cluster’s CNI redirects its traffic to the local ztunnel. This redirection happens transparently and applies to traffic between pods on the same node as well as pods on different nodes. From the application’s perspective, it is still sending and receiving plain TCP traffic.
This model allows platform teams to enable mTLS incrementally and consistently across the cluster, without modifying deployments or coordinating with application owners.
Identity and Authentication Without Sidecars
Removing sidecars raises an obvious question: how are workload identity and mutual authentication preserved?
In a traditional mesh, the sidecar holds the certificate and handles the handshake. With Istio Ambient Mesh, the ztunnel performs these duties on behalf of the pods. Even though the ztunnel is a shared node-level component, it cannot use a single “node identity” for all traffic but must securely fetch and manage individual certificates for every pod running on the node:
To preserve strong workload identity, ztunnel performs certificate management on behalf of each pod:
- It requests a unique X.509 certificate for each workload identity from the Istio control plane
- The control plane verifies that the ztunnel is authorized to represent those workloads before issuing certificates
When Pod A communicates with Pod B, the TLS handshake uses Pod A’s identity, not a shared node identity. mTLS still requires both sides to present valid certificates, preserving the same security guarantees as a sidecar-based mesh.
mTLS requires that both parties present valid certificates before connecting
HBONE and the Transport Layer
To provide node-to-node mTLS without exposing this complexity to applications, Ambient Mesh relies on a transport overlay. To facilitate secure communication between nodes, Istio Ambient Mode uses a protocol called HBONE (HTTP-Based Overlay Network Enveloping). It is a way to tunnel standard TCP traffic through an encrypted mTLS connection using HTTP/2 CONNECT, creating a secure overlay across the cluster.
The mTLS Flow in Ambient Mode
When a request travels between two pods in Ambient Mode, the flow looks like this:
- Pod A sends a TCP packet as usual
- The packet is redirected by the CNI to the local ztunnel
- The source ztunnel selects Pod A’s certificate and establishes an HBONE connection to the destination node
- The destination ztunnel presents Pod B’s certificate and validates Pod A’s identity
- Once the handshake completes, session keys are exchanged and traffic flows through the encrypted tunnel
- The destination ztunnel decrypts the traffic and forwards the original TCP packet to Pod B
This prevents eavesdropping and service impersonation, significantly reducing the risk of lateral movement.
All traffic between pods is encrypted whether they are running on the same node or different nodes
Separating Layer 4 Security From Layer 7 Processing
Treating mTLS as infrastructure requires minimizing how much application context the platform needs to understand. For this reason, a key design choice in Ambient Mesh is the separation of concerns between Layer 4 and Layer 7.
As discussed earlier, ztunnel operates strictly at Layer 4, handling encryption, authentication, and identity-based authorization without inspecting application protocols or performing traffic shaping.
Layer 7 features such as routing, retries, and request-level authorization are handled by waypoint proxies, which are only deployed where needed. This allows teams to apply application-level policies selectively instead of paying the cost everywhere.
For many clusters, this means mTLS can be enabled universally, while Layer 7 features are introduced incrementally and intentionally.
Ambient Mesh and Calico Network Policy
Encryption and identity establish who is communicating, but zero trust also requires controlling which communications are allowed. Network policy addresses this by limiting which workloads are permitted to communicate in the first place.
Calico provides enforcement of Kubernetes NetworkPolicy and GlobalNetworkPolicy at the CNI level. These policies operate independently of the service mesh and apply consistently across all workloads.
When used together, Calico and Istio Ambient Mesh complement each other in the following ways:
- ztunnel ensures traffic is encrypted and authenticated
- Calico policies control which connections are permitted
- Existing network policies continue to apply, even with HBONE traffic
- Enforcement happens below the application, reducing reliance on app-level configuration
Calico’s implementation preserves the original destination information of traffic, which allows policies to continue functioning as expected. This avoids a common concern when introducing overlays or tunnels into a cluster.
For a deeper discussion of how Calico integrates with Ambient Mesh, read An In-Depth Look at Istio Ambient Mode with Calico.
Operational Impact
By moving mTLS into a shared, node-level component, Ambient Mesh changes the operational profile of a service mesh:
- No per-pod sidecars
- No application restarts to enable encryption
- Lower CPU and memory overhead
- Clear separation between infrastructure security and application traffic management
For teams that previously found sidecar-based meshes difficult to operate at scale, this model offers a different set of tradeoffs that may be easier to manage.
A Shift in How mTLS Is Delivered
Beyond these operational improvements, Ambient Mesh also represents a fundamental shift in how mTLS is delivered. By treating encryption and identity as infrastructure concerns rather than application concerns, ztunnel provides node-level mTLS while preserving workload identity without requiring sidecar proxies.
When combined with Calico’s network policy enforcement, Ambient Mesh fits into a broader zero-trust approach that emphasizes defense in depth, operational simplicity, and clear separation of responsibilities.
Strengthen Your Zero-Trust Strategy
Moving mTLS to the infrastructure layer provides a more scalable and transparent approach to operational simplicity. Ready to see how Ambient Mesh and Calico work together to secure your cluster without the sidecar tax?
- An In-Depth Look at Istio Ambient Mode with Calico
- How Istio Ambient Mode Delivers Real-World Solutions
- How Calico and Istio Implement Zero Trust
Start Free Trial → Request a Demo →
The post Sidecarless mTLS in Kubernetes: How Istio Ambient Mesh and ztunnel Enable Zero Trust appeared first on Tigera - Creator of Calico.
Top comments (0)