Architecture

An ambient mesh is logically split into a data plane and a control plane.

• The data plane is composed of a set of programmable proxy servers, also referred to as ztunnels and waypoint proxies. These proxies mediate and control all network communication, and collect and report telemetry on all mesh traffic. Compared to traditional service mesh architectures, where the proxy servers are deployed as “sidecars” next to every workload, ambient mesh uses proxy servers that are operated by the cluster administrator.

• The control plane (istiod) manages and configures the proxies in the data plane.

Control plane component

Review the component that makes up the ambient mesh control plane.

Istiod

The Istio control plane istiod provides service discovery, configuration, and certificate management for your ambient mesh. When new configuration becomes available, istiod rolls out this configuration to the ztunnels and waypoint proxies in the cluster at runtime. Istiod is typically deployed as a single instance per service mesh. However, depending on your environment, you can operate istiod in high availability mode as well.

To enable mTLS connections between ztunnel sockets and waypoint proxies, istiod acts as a Certificate Authority (CA) to generate and sign TLS certificates. The certificates are used by the ztunnel sockets and waypoint proxies to do mutual TLS authentication.

Data plane components

Review the components that make up the ambient mesh data plane.

ztunnel

The ztunnel (Zero Trust tunnel) component is a lightweight, purpose-built proxy that is deployed as a daemon set on every node in the cluster.

Ztunnel is responsible for securely connecting and authenticating workloads within the mesh. The ztunnel proxy is written in Rust and is intentionally scoped to handle L3 and L4 functions such as mTLS, authentication, L4 authorization, and telemetry.

All ingoing and outgoing traffic to the pods is automatically intercepted and secured by the ztunnel socket that is exposed on the pod. The socket is configured by the ztunnel that is co-located on the same node as the pod. The ztunnel socket forwards traffic to the ztunnel socket of the target pod. If the target pod is located on a different node, its ztunnel socket is configured by the ztunnel instance that is co-located on the same node as the pod. The communication between the ztunnel sockets is secured via mutual TLS (mTLS).

Ztunnel sockets can also efficiently and securely transport traffic to workloads directly or to waypoint proxies. The reference implementation of ztunnel in Istio does not terminate workload HTTP traffic or parse workload HTTP headers. You must create waypoint proxies to handle L7 HTTP traffic.

Ingress gateways and waypoints

An ingress gateway is a proxy server deployed at the edge of the mesh and used to route traffic into or out of the mesh. You typically have one ingress gateway per service mesh.

A waypoint proxy is a proxy server deployed inside the mesh and used to add HTTP or other L7 features to traffic between services in the mesh. Waypoint proxies are shared between apps in the same namespace or service account.

To enforce a Layer 7 policy for an app, you must manually deploy a waypoint proxy to the cluster. Then, when a request is sent to a target app that has L7 policies applied, the request is forwarded from the client pod’s ztunnel socket to the waypoint proxy. The waypoint proxy enforces the L7 policy and collects L7 metrics before the request is forwarded to the ztunnel socket of the target app. Traffic between the ztunnel socket and the waypoint proxy is secured via mTLS by default.

Many ambient mesh use cases can be addressed solely with ztunnel, and do not require a waypoint proxy. Ambient mesh is designed so that you can transparently add and remove waypoint proxies as required by your use case.

Both gateways and waypoints are deployments of the Envoy proxy, a high-performance L7 proxy server. They run outside of application pods and are installed, upgraded, and scaled independently from applications.

To learn how to set up waypoint proxies, check out the Create waypoint proxies guide.

East-west gateways

To facilitate and route traffic in a multicluster ambient mesh, you must set up east-west gateways on each cluster that is part of the mesh. When a request from an ingress gateway or in-mesh app in one cluster must be sent to an in-mesh app in another cluster, the request is first sent to the east-west gateway of the target app’s cluster. The east-west gateway is implemented as a ztunnel, and uses “double HBONE” to facilitate routing. In ambient mode, HBONE is used as the transport protocol.

When a request is sent to the east-west gateway, double HBONE opens a tunnel that uses an outer mTLS layer and inner mTLS layer. The east-west gateway terminates the outer layer of the tunnel, along with the outer mTLS connection from the app or gateway that sent the request, and performs authentication. The east-west gateway then opens an inner mTLS connection to the ztunnel socket of the target app to securely forward the request.

Istio CNI

The Istio CNI plug-in is deployed as a daemon set on every node of the cluster and monitors all pods that are created or removed from the ambient mesh. For all pods that participate in the ambient mesh, the CNI plug-in configures the redirect from the app to the ztunnel.

Network architecture

Review how traffic is routed within a multicluster ambient mesh.