Overview

Explore ambient mesh, an Istio service mesh without sidecars.

What is ambient mesh?

Engineers from Solo.io collaborated with Google to develop ambient mesh, a new “sidecarless” architecture for the Istio service mesh. An ambient mesh is a service mesh that operates independently of the workloads that are enrolled in it. Compared to a traditional (“sidecar”) service mesh, where a proxy server is injected as a sidecar into your apps and implements all data plane functionality, an ambient mesh splits the functionality related to network routing and transport security (Layer 3 and Layer 4 of the OSI model, generally referred to as “L4”) and the functionality related to HTTP or other application protocols (Layer 7, or “L7”).

To route Layer 4 traffic between apps, ambient mesh uses a shared, node-level proxy, also referred to as ztunnel. The ztunnel provides a secure overlay layer and is operated separately from a user’s application. Layer 7 functionality and policy enforcement are provided by waypoint proxies. Apps within the same security boundary, such as the same Kubernetes namespace, typically share the same waypoint proxy. This architecture significantly reduces the complexity of adopting a service mesh. But, you still get the benefits of Istio, such as secure mutual TLS (mTLS) for pod-to-pod communication.

To onboard apps into the ambient mesh, you simply label the namespace the app belongs to. Because no sidecar must be injected, you don’t need to worry about restarting or reconfiguring your apps. Your apps automatically become part of the ambient mesh.

How does it work?

Ambient mesh layers on top of a cloud native environment to transparently enable zero-trust security, observability, and advanced traffic management. Compared to a traditional sidecar service mesh, the user that deploys the app in an ambient mesh does not see and is not responsible for any of the service mesh infrastructure. Instead, the service mesh infrastructure is provided by the environment that the app runs in.

Consider a client pod that wants to connect to a server pod within a Kubernetes environment:

In an ambient mesh, the secure overlay layer is provided by ztunnels. The ztunnel is a zero trust, lightweight proxy that handles only Layer 4 traffic and zero trust security in the ambient mesh. It is deployed as a daemon set on every node of the cluster. All incoming 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 of the node then forwards traffic to the ztunnel socket of the target pod. The communication between the ztunnel sockets is secured via mutual TLS.

Above L4, when needed, users can enable L7 waypoint proxies to get access to the full range of service mesh features. The waypoint proxies, while heavier than the ztunnel overlay alone, still run as an ambient component of the infrastructure and require no modifications to app pods.

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.

What service mesh architecture is right for me?

You might wonder whether you should use a sidecar or ambient (sidecarless) architecture. Your approach depends on the requirements that your apps need to meet, including security, visibility, and lifecycle operations. You can even use both modes of Istio in the same service mesh. With this interoperable approach, you can use the mode that is best for your app. Let’s take a look at the benefits each architecture offers:

Benefit	Ambient mesh	Sidecar mesh
Deployment model	No sidecar proxy in each pod; uses shared Layer 4 and optional Layer 7 waypoint proxies.	Each app pod includes a dedicated sidecar proxy.
Mutual TLS (mTLS)	mTLS enforced between workloads through ztunnel sockets.	mTLS enforced per pod with stronger, pod-specific identity.
Resource usage	Less CPU and memory overhead due to fewer proxies.	Higher resource usage as each sidecar consumes additional resources.
Service mesh onboarding	Easier onboarding with no app configuration changes. Simpler lifecycle operations by not having to restart the app.	Apps might require configuration changes and must be restarted after sidecars are injected.
Network layer	Primarily Layer 4 (transport); Layer 7 only when needed via waypoint proxies.	Always Layer 7 (application layer).
Performance	Greater network performance due to reduced Layer 7 processing overhead.	Slightly lower performance due to Layer 7 inspection and processing.
Vulnerability risk	Smaller risk of CVEs on Layer 4 vs. Layer 7.	Reduced vulnerability surface, because any compromise impacts only that app.
Visibility & observability	Limited by default due to the focus on Layer 4. Full Layer 7 visibility requires waypoints or the Solo distribution of Istio.	Full Layer 7 visibility into traffic for metrics, logs, and tracing.

For detailed information about ambient mesh, see this Istio blog.