Transparent Traffic Interception in Istio Ambient Mode: A Comprehensive Explanation

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:

×

Detailed Steps of Traffic Interception

1. 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.
2. 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.
3. Ztunnel Starts Listening Sockets in Pod Network Namespace:
   1. ztunnel receives the namespace FD and starts listening sockets within it to handle redirected traffic.
4. 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

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