A curated list of AI tools and resources for developers, see the AI Resources .

Istio Ambient Mode: Illustrated Terminology and Concept Interpretation

This article provides a detailed glossary of Istio Ambient Mode, helping you understand its key concepts and underlying technical implementation.

Feb 13, 2025 • Service Mesh • 7 Minute • 1536 words

Istio Ambient Mode is an innovative, sidecarless service mesh deployment approach. By separating data plane functions into ztunnel and waypoint proxy, it simplifies operations and reduces resource consumption. This blog presents a comprehensive glossary to help you better understand the key concepts and technical mechanisms behind Istio Ambient Mode.

Ambient Mode

Figure 1: Ambient Mode Architecture
Figure 1: Ambient Mode Architecture

Ambient Mode is a lightweight, sidecarless data plane model in Istio, implemented via ztunnel and waypoint proxy to enable secure communication and management between services. Compared to the traditional Sidecar model, Ambient Mode is more efficient, reduces resource usage, and simplifies configuration.

  • Architecture: The data plane is split into an L4 security overlay (provided by ztunnel) and an L7 policy processing layer (provided by waypoint proxy).

Control Plane and Data Plane

Figure 2: Control Plane and Data Plane
Figure 2: Control Plane and Data Plane

In Ambient Mode, the control plane (istiod) manages the configuration and policies for ztunnel and waypoint proxy across the cluster. The data plane consists of ztunnel and waypoint proxy, which handle actual network traffic.

  • Component Interaction: ztunnel uses xDS APIs to fetch configuration and enforce policies from istiod, managing L4 and L7 traffic between Pods.

Istio Control Plane (istiod)

istiod is Istio’s control plane component, responsible for communicating with ztunnel and waypoint proxy and providing xDS interfaces for dynamic configuration.

  • Functions: istiod pushes configuration via xDS APIs, dynamically manages traffic policies, certificate distribution, and interacts with the Kubernetes cluster.

Transparency and Non-Intrusiveness

Ambient Mode is designed to minimize intrusion into applications. Workloads can join the mesh without restarting Pods or injecting sidecars, making the data plane invisible to applications.

  • Advantages: Enhances service mesh flexibility, reduces operational complexity, and decouples application and infrastructure lifecycles.

Sidecar Proxy

Figure 3: Sidecar Mode
Figure 3: Sidecar Mode

The traditional Istio model uses Envoy sidecar proxies deployed alongside application containers within each Pod.

  • Issues: Sidecars are intrusive, must be injected into Pods, increase resource overhead, and tightly couple the lifecycle of applications and proxies.

Ztunnel (Zero-Trust Tunnel)

Figure 4: ztunnel
Figure 4: ztunnel

Ztunnel is a core component of Ambient Mode, deployed as a DaemonSet to provide L4 zero-trust tunnels for each node.

  • Functions:
    • Security: Provides mTLS encryption and SPIFFE ID-based authentication for secure communication between nodes and workloads.
    • Observability: Collects L4 TCP metrics and logs.
    • Connection Multiplexing and Balancing: Establishes secure tunnels between nodes to optimize connections and network performance.
    • Multi-Tenancy: A single ztunnel can represent multiple workloads on the same node for L4 data plane functions, unlike the Sidecar model where each Pod has its own proxy.
    • Certificate Management: ztunnel obtains mTLS certificates from the Istio control plane (istiod) on behalf of all Pods on the node and manages certificate rotation.
  • Interfaces:
    • pistioin and pistioout: Connect to the node’s istioin and istioout interfaces via GENEVE tunnels.

Waypoint Proxy

Figure 5: Waypoint Proxy
Figure 5: Waypoint Proxy

Waypoint Proxy is the L7 proxy in Ambient Mode, deployed at the namespace level to handle L7 requests.

  • Functions: Provides L7 authorization policies, such as HTTP header-based access control and L7 telemetry. Only required L7 traffic is processed by Waypoint Proxy; other L4 traffic is handled by ztunnel.

GENEVE Tunnel (Generic Network Virtualization Encapsulation)

Figure 6: GENEVE Protocol Structure
Figure 6: GENEVE Protocol Structure

GENEVE tunnels are used to establish virtual connections between Kubernetes nodes, forwarding traffic from node Pods to ztunnel.

  • Application in Ambient Mode: GENEVE tunnels connect the node’s virtual network interfaces (istioin and istioout) to the corresponding interfaces (pistioin and pistioout) inside ztunnel.

HBONE (HTTP-Based Overlay Network Environment)

Figure 7: HBONE Packet Format
Figure 7: HBONE Packet Format

HBONE is Istio’s proprietary secure tunnel protocol for data transmission between Ambient Mode components. It is an mTLS-encrypted channel built on HTTP/2 and HTTP CONNECT.

  • Implementation: Uses HTTP/2 for multiplexing, HTTP CONNECT for tunnel establishment, and mTLS for security. See Istio documentation for details.

Istioin and Istioout Virtual Interfaces

Figure 8: Ambient Mode Pod Routing
Figure 8: Ambient Mode Pod Routing

These are two virtual interfaces configured on each node by the Istio CNI plugin to handle inbound and outbound traffic.

  • Functions: istioin handles inbound traffic, istioout handles outbound traffic. Both are connected to ztunnel via GENEVE tunnels.

iptables and Traffic Redirection

iptables is used to configure Linux kernel traffic rules, redirecting and marking traffic from Ambient workloads.

  • Application in Ambient Mode: The Istio CNI plugin uses iptables rules to mark and redirect traffic to istioin or istioout, which is then sent to ztunnel via GENEVE tunnels.

Traffic Interception and Redirection

In Ambient Mode, ztunnel transparently intercepts all traffic to and from “in-mesh” Pods, encrypts it, and redirects it to the target Pod on another node, ensuring compliance with mesh security policies.

  • Mechanism: Using iptables rules or eBPF programs installed by the Istio CNI plugin, ztunnel can transparently capture workload traffic and securely proxy it without modifying client applications.

Traffic Path Classification

  • Out of Mesh: Pods not part of the service mesh; traffic is not processed by the Ambient data plane.
  • In Mesh: Pods included in the Ambient data plane; L4 traffic is intercepted and processed by ztunnel, providing L4 authorization and encryption.
  • In Mesh, Waypoint Enabled: Pods in the Ambient data plane with waypoint proxy enabled; L7 traffic is processed by waypoint for advanced policy enforcement.

TPROXY

Figure 9: TPROXY Transparent Proxy
Figure 9: TPROXY Transparent Proxy

TPROXY is a Linux kernel feature for transparent interception and redirection of network traffic.

  • Application in Ambient Mode: ztunnel uses TPROXY to intercept and process traffic, preserving original source IP and port information for transparent proxying.

Mutual TLS (mTLS)

Figure 10: Istio mTLS Process
Figure 10: Istio mTLS Process

Mutual TLS is a bidirectional TLS authentication mechanism ensuring both parties are authenticated and data is encrypted.

  • Application in Ambient Mode: mTLS encryption between workloads is enforced via ztunnel and waypoint proxy, achieving zero-trust security.

See Understanding TLS Encryption in Istio

SPIFFE ID

Figure 11: SPIFFE ID Format
Figure 11: SPIFFE ID Format

All workloads in the Istio service mesh register a SPIFFE-standard service identity: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

  • Definition: An identifier for workload identity management in the mesh.
  • Application in Ambient Mode: SPIFFE ID is used for node and workload authentication to secure network communication.

eBPF (Extended Berkeley Packet Filter)

eBPF is a Linux kernel technology for running sandboxed programs in kernel space, enabling advanced packet processing.

  • Application in Ambient Mode: eBPF can replace traditional iptables and GENEVE tunnels for traffic redirection and management. It is more efficient, less complex, and easier to manage.
  • eBPF Programs:
    • Application inbound
    • Application outbound
    • Ztunnel host inbound
    • Ztunnel inbound
  • Role: Istio CNI mounts eBPF programs at specific TC points to process application and ztunnel network traffic.

Waypoint Proxy Elastic Scaling

Figure 12: Waypoint Proxy Scaling
Figure 12: Waypoint Proxy Scaling

In Ambient Mode, waypoint proxy can scale dynamically based on traffic demand, without deploying a dedicated proxy for each workload instance.

  • Advantages: Dynamic scaling of waypoint proxy reduces infrastructure costs and improves resource utilization.

Ztunnel Elasticity and Fault Recovery

Ztunnel is deployed as a DaemonSet. If a ztunnel container fails, Kubernetes automatically reschedules it to ensure continued node traffic processing.

  • Feature: Minimizes the impact of failures, affecting only workloads on the affected node.

IP Set and ztunnel-pods-ips

IP Set is a tool for storing IP addresses; ztunnel-pods-ips is a set on each node for Ambient mesh Pod IPs.

  • Application in Ambient Mode: The Istio CNI plugin adds each Ambient mesh Pod IP to ztunnel-pods-ips to ensure traffic is recognized and processed by iptables rules.

Connection Multiplexing

Connection multiplexing is the technique of transmitting multiple logical connections over a single physical connection.

  • Application in Ambient Mode: ztunnel implements connection multiplexing, allowing multiple workloads to share the same connection and improving network efficiency.

Node Network Virtual Interface Pair (veth)

Each Pod creates a virtual interface pair on the node at runtime, connecting the Pod’s network to the node’s network.

  • Application in Ambient Mode: veth interfaces connect Pod traffic to the node’s virtual interfaces (istioin and istioout), directing traffic to ztunnel for processing.

Waypoint Proxy Traffic Path

Figure 13: Waypoint Proxy Routing Path
Figure 13: Waypoint Proxy Routing Path

Waypoint Proxy only participates in the server-side traffic path, acting as an L7 proxy for server requests.

  • Use Case: When Waypoint Proxy is deployed, workloads sharing the same service account are redirected via ztunnel to Waypoint Proxy for processing, then to the target Pod, ensuring L7 policy and authentication enforcement.

Istio CNI (Container Network Interface)

Istio CNI is Istio’s container network interface plugin for automatically configuring traffic interception rules in Kubernetes clusters.

  • Functions: Istio CNI sets up network redirection rules for each new or mesh-joined Pod. It modifies iptables rules or applies eBPF programs to ensure all traffic is intercepted and processed by ztunnel or waypoint proxy, enabling transparent mesh traffic management.
  • Istio CNI Node Agent: The Node Agent installs the Istio CNI plugin on each node and updates the node’s CNI configuration, ensuring proper network redirection when Pods join the mesh. In Sidecar mode, the CNI plugin configures Pod networking via iptables. In Ambient Mode, it pushes new Pod events to the Ambient monitoring server for network redirection configuration.

Summary

Istio Ambient Mode divides data plane functions into independent L4 and L7 components, providing users with a lightweight and flexible service mesh solution. This approach simplifies service deployment and significantly reduces resource overhead. Through this glossary, we’ve explored the core concepts of Ambient Mode—from ztunnel and waypoint proxy to iptables and eBPF—helping you gain a comprehensive understanding of Istio Ambient Mode’s architecture and operation. If you’re interested in service mesh or considering how to optimize microservice communication, we hope this article proves helpful.

Post Information

Updated on Nov 16, 2025 HBONE Istio Istio Ambient

Post Navigation

Related Articles

Comments