Ambient mesh is a simpler, sidecar-less approach to securing communication within Kubernetes clusters. However, there’s a common misconception that Istio’s ambient mode provides mTLS only for traffic between pods or ztunnels running on different nodes. This misunderstanding often stems from overly simplified diagrams or explanations, leaving many to assume that intra-node traffic remains unencrypted.
The truth is, Ambient mesh provides mTLS for all traffic—including communication between pods on the same node. This blog post covers how Istio’s Ambient mode achieves this, focusing on how and when ztunnel gets into the traffic path, without going too deep into linux networking.
At the heart of Istio Ambient mode is the ztunnel, a lightweight, Layer 4 proxy deployed as a DaemonSet on every Kubernetes node providing mTLS, authentication, L4 authorization and L4 telemetry and additional HTTP metrics when using Gloo. When two pods communicate, ztunnel transparently intercepts, encrypts, and forwards the traffic.
The details of the traffic capture is documented on istio.io, but here’s how it works:
Socket listener inside the source pod network to intercept outbound traffic
Istio uses a CNI Plugin to configure ztunnel to set up a socket listener directly inside the network namespace of the source pod. This enables ztunnel to capture outbound traffic as it originates, similar to how it works with sidecars.
Only encrypted traffic leaves the pod network
Once the traffic is intercepted, ztunnel encrypts it with the x509 certificates it holds for every workload on the node, and the HBONE encapsulated traffic leaves the pod network namespace.
Socket listener inside the destination pod network to intercept incoming traffic
Just like for outbound, a node local ztunnel is set up to directly capture inbound traffic as well. ztunnel will decrypt the traffic, enforce any authentication policies, and then pass it on to the destination container.
This process ensures that there is consistent security for all traffic:
- Intra-node and inter-node traffic flows are identical, applying the same security regardless of whether the communication is local or across nodes.
- Plaintext traffic does not leave a pod’s network namespace, guaranteeing end-to-end encryption and zero-trust compliance.
- By handling encryption and traffic interception transparently, ztunnel simplifies network security without sidecars.
No policies are required to encrypt traffic between pods. For fine grained access control, you can create AuthorizationPolicies with rules specifying source, destination, and conditions. These policies are based on workload identity, leveraging SPIFFE-compliant identities rather than relying on traditional network-based identifiers like IP addresses, making it a better fit in dynamic environments. The following example creates a rule that only productpage is allowed to call ratings. This is enforced by ztunnel when traffic arrives at the ratings pod.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: ratings-viewer
namespace: default
spec:
selector: # where to apply the policy
matchLabels:
app: ratings
action: ALLOW # or DENY, AUDIT or CUSTOM
rules:
- from:
- source:
principals: # can also be namespace or ip blocks
- cluster1/ns/default/sa/productpage
If you’re looking to dive deeper, check out the KubeCon North America 2024 talk by John Howard and Keith Mattix, ‘Life of a Packet: Ambient Edition.’
Ambient mesh ensures mTLS for all traffic, including communication between pods on the same node. By setting up socket listeners in the pod network namespaces, ztunnel captures and encrypts traffic before it leaves the source pod and decrypts it only after it reaches the destination pod. With Ambient mesh, you get secure, consistent, and sidecar-less communication across your entire Kubernetes cluster—whether traffic stays local or spans nodes.
Learn more about Ambient mesh here or deep dive into our free labs to test it out now!
