Transparent Traffic Interception in Istio Ambient Mode: A Comprehensive Explanation

This is the first article in my series on Istio ambient mode. In the upcoming posts, I will delve deeper into the key components and their working principles, including how ztunnel forwards traffic to the waypoint proxy, how the waypoint proxy handles the traffic, and a comprehensive analysis of the traffic path using the Bookinfo example. Since traffic interception is the foundation of service mesh functionality, I chose to start with it to provide a solid understanding.

Istio ambient mode is a service mesh implementation that eliminates the need for sidecar injection into each pod. By configuring transparent traffic interception and redirection within the pod’s network namespace, applications can leverage service mesh capabilities without any modifications. The following content provides a detailed explanation of the transparent traffic interception process, covering components such as Istio CNI node agent, ztunnel, network namespaces, and iptables rules, illustrated with flowcharts and diagrams.

Tetrate offers an enterprise-ready, 100% upstream distribution of Istio, Tetrate Istio Subscription (TIS). TIS is the easiest way to get started with Istio for production use cases. TIS+, a hosted Day 2 operations solution for Istio, adds a global service registry, unified Istio metrics dashboard, and self-service troubleshooting.
Get access now ›

Background Knowledge

Linux Network Namespaces

Network namespaces are a Linux kernel feature used to isolate the network environment of different processes. Each network namespace has its own network devices, IP addresses, routing tables, and iptables rules. Container technologies (e.g. Docker, Kubernetes) use network namespaces to provide each container (or pod) with an isolated network stack.

Istio CNI Node Agent

Istio CNI Node Agent is a core component of ambient mode that operates on Kubernetes nodes, detecting pods joining the Ambient mesh and configuring traffic redirection rules for these pods. Note that this involves the Istio CNI Node Agent, not the traditional Istio CNI plugin. The Node Agent acts as a daemon working alongside ztunnel but does not directly perform network plugin tasks.

ztunnel

ztunnel is a critical component in ambient mode, running as a DaemonSet on each node. Its responsibilities include:

Receiving and processing redirected traffic.
Enforcing L4 policies such as mTLS encryption and access control.
Communicating with the control plane to obtain configurations and certificates.

HBONE

HTTP-Based Overlay Network Encapsulation(HBONE) is a protocol introduced by Istio for transmitting arbitrary TCP traffic between ztunnel and waypoint proxy. HBONE leverages HTTP/2 and HTTP/3 multiplexing and encryption features for enhanced communication efficiency and security.

Detailed Traffic Interception Process

In ambient mode, application pods require no code changes or sidecar injection. Traffic interception and redirection occur entirely within the pod’s network namespace, avoiding conflicts with the underlying CNI. Here’s an overview of the steps involved:

**Figure 1:** *Traffic interception process in Istio ambient mode.*

Detailed Steps of Traffic Interception

Pod Initialization and Network Configuration:
1. When Kubernetes creates a pod, it invokes the underlying CNI plugin (e.g., Calico, Cilium) via the Container Runtime Interface (CRI) to configure the pod’s network.
2. At this stage, the pod’s network namespace (netns) is established.
Istio CNI Node Agent Configures Traffic Redirection:
1. The Istio CNI Node Agent detects that the new pod is marked for ambient mode (via the label istio.io/dataplane-mode=ambient).
2. It enters the pod’s network namespace and sets up iptables rules for traffic interception.
3. The network namespace’s file descriptor (FD) is passed to ztunnel.
Ztunnel Starts Listening Sockets in Pod Network Namespace:
1. ztunnel receives the namespace FD and starts listening sockets within it to handle redirected traffic.
Transparent Traffic Interception and Processing:
1. Traffic originating from the application is intercepted by the iptables rules in the pod and transparently redirected to ztunnel.
2. ztunnel performs policy checks, encryption, and other processing before forwarding traffic to the target service.
3. Responses are decrypted by ztunnel and returned to the application.

For more details about how Istio CNI configures iptables, see my other blog post: Analyzing iptables Rules in Istio ambient mode.

ztunnel Log Analysis

You can inspect all logs related to traffic interception in ztunnel using the following command, which helps you understand how ztunnel operates:

kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"

The logs will look like the examples below, where inbound and outbound are relative to ztunnel.

Inbound Traffic Example

2024-11-16T10:33:01.410751Z info  access  connection complete src.addr=10.28.2.19:58000 src.workload="bookinfo-gateway-istio-64fc6d75d6-s442s" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/bookinfo-gateway-istio" dst.addr=10.28.2.18:15008 dst.hbone_addr=10.28.2.18:9080 dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-57ffb6658c-tgbjs" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="inbound" bytes_sent=9603 bytes_recv=2052 duration="2110ms"

This log describes inbound traffic from bookinfo-gateway-istio to the productpage service, passing through ztunnel’s port 15008, encrypted via HBONE, with identities verified through SPIFFE.

Outbound Traffic Example

2024-11-16T10:32:59.360677Z info  access  connection complete src.addr=10.28.2.18:51960 src.workload="productpage-v1-57ffb6658c-tgbjs" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" dst.addr=10.28.2.14:15008 dst.hbone_addr=34.118.226.6:9080 dst.service="details.default.svc.cluster.local" dst.workload="waypoint-7594b5b786-vgjwz" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/waypoint" direction="outbound" bytes_sent=794 bytes_recv=414 duration="40ms"

This log shows outbound traffic from the productpage pod to the details service, routed through ztunnel using an HBONE tunnel to the waypoint pod (port 15008).

Conclusion

Istio ambient mode achieves sidecar-free transparent traffic interception through the collaboration of Istio CNI Node Agent and ztunnel. Key features include:

High compatibility: Avoids conflicts with underlying CNI.
Simplified operations: No need for application code changes, reducing resource overhead.
Enhanced security: Enables end-to-end encrypted transmission with HBONE.

In future articles, I will explore advanced features of Istio ambient mode, including L7 traffic path analysis and network topology construction. Stay tuned!

References

###

If you’re new to service mesh, Tetrate has a bunch of free online courses available at Tetrate Academy that will quickly get you up to speed with Istio and Envoy.

Are you using Kubernetes? Tetrate Enterprise Gateway for Envoy (TEG) is the easiest way to get started with Envoy Gateway for production use cases. Get the power of Envoy Proxy in an easy-to-consume package managed by the Kubernetes Gateway API. Learn more ›

Getting started with Istio? If you’re looking for the surest way to get to production with Istio, check out Tetrate Istio Subscription. Tetrate Istio Subscription has everything you need to run Istio and Envoy in highly regulated and mission-critical production environments. It includes Tetrate Istio Distro, a 100% upstream distribution of Istio and Envoy that is FIPS-verified and FedRAMP ready. For teams requiring open source Istio and Envoy without proprietary vendor dependencies, Tetrate offers the ONLY 100% upstream Istio enterprise support offering.

Need global visibility for Istio? TIS+ is a hosted Day 2 operations solution for Istio designed to simplify and enhance the workflows of platform and support teams. Key features include: a global service dashboard, multi-cluster visibility, service topology visualization, and workspace-based access control.

Get a Demo

Article content