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.

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 (HTTP-Based Overlay Network Encapsulation) 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:

Detailed Steps of Traffic Interception

1. Pod Initialization and Network Configuration:
   • 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.
   • At this stage, the pod’s network namespace (netns) is established.
2. Istio CNI Node Agent Configures Traffic Redirection:
   • The Istio CNI Node Agent detects that the new pod is marked for ambient mode (via the label istio.io/dataplane-mode=ambient).
   • It enters the pod’s network namespace and sets up iptables rules for traffic interception.
   • The network namespace’s file descriptor (FD) is passed to ztunnel.
3. Ztunnel Starts Listening Sockets in Pod Network Namespace:
   • ztunnel receives the namespace FD and starts listening sockets within it to handle redirected traffic.
4. Transparent Traffic Interception and Processing:
   • Traffic originating from the application is intercepted by the iptables rules in the pod and transparently redirected to ztunnel.
   • ztunnel performs policy checks, encryption, and other processing before forwarding traffic to the target service.
   • 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

• Maturing Istio Ambient: Compatibility Across Various Kubernetes Providers and CNIs
• Introducing Istio Ambient Mesh
• Kubernetes Official Documentation: Network Plugins
• HBONE
• ztunnel Traffic Redirection

This blog was initially published at tetrate.io.