One of the main reasons for the popularity and adoption of service meshes is that they bring a much improved security posture to microservices architectures.
Istio is the most widely adopted service mesh. Today, the Istio project offers a mode known as ambient mesh which departs from the original sidecar-based model. Ambient mesh represents an evolution of the service mesh platform, with a focus on efficiency and isolation.
This article explains how ambient mesh enhances security beyond what the sidecar model could achieve.
How service meshes improved security posture
Prior to service meshes, as enterprises migrated from monolithic applications to microservices, the security model was based on the concept of perimeter security. Internally, microservices communicated with one another without encryption and without workload identity: services implicitly trusted one another.
In an attempt to improve the security posture, additional burden was placed on application teams to bundle certificates into their applications and secure communications with other services. This approach was complex, error prone, difficult to maintain, and did not scale.
As service meshes such as Istio emerged, they brought with them a rigorous and systematic way of securing network communications. Workloads were automatically issued cryptographic identities, which were automatically rotated and used to encrypt and authenticate network communications. In Istio, the control plane arranged for the Envoy sidecars to have access to identity certificates, used to establish a mutual TLS handshake with other services in the mesh.
Thanks to service meshes, organizations were finally able to realize a secure, "zero-trust" environment where all traffic between microservices was encrypted and authenticated.
Ambient review - the mesh, grown up
Ambient mesh is in some ways a major departure from its original design in that it does away with the sidecar model. But in other ways, things remain very much the same: we still get workload identity and mutual TLS, encryption of traffic between microservices.
Both the Istio documentation and ambientmesh.io, a site dedicated to all things ambient mesh, go into detail explaining how this sidecar-less mesh functions without the aid of sidecars.
The process involves several components. The Istio CNI agent assists with traffic capture and network redirection through ztunnel (z for "zero trust"), a new per-node layer 4 proxy. One of ztunnel's responsibilities is the handling of network identities and mutual TLS communication on behalf of the workloads running on its node.
Where layer 7 policy enforcement is required, we can independently provision waypoints (layer 7 proxies based on Envoy) on demand in the path of requests between services. The end result is a less invasive mesh layer, from the perspective that no "surgery" is required on your workloads to accomplish mesh policy enforcement.
Let us review some of the benefits derived from no longer needing to inject a sidecar into every pod:
- Simplicity: reminiscent of the adage "the best part is no part", which asserts that the most effective and reliable systems are those with the fewest components and the least complexity.
- Efficiency: not running an Envoy sidecar inside every pod has huge ramifications in terms of resource use and requirements.
- Cost savings: a direct consequence of the previous point, the higher efficiency translates directly into compute and memory cost savings.
- Operational gains: a consequence of the fact that mesh components are no longer tangled with application workloads translates to simpler operations -- we can install and upgrade the mesh platform without disturbing` running applications, and vice versa: we can deploy and upgrade our applications without having to deal with the sidecars.
Another aspect that benefits from ambient's design is security.
Security benefits
Let us assess ways in which ambient mesh improves the security posture of a system of microservices over a sidecar-based mesh.
Reduced attack surface
In sidecar mode, the presence of Envoy sidecars with full layer 7 capabilities inside each and every pod represents a much larger attack surface. In ambient, a workload requiring only mTLS can use ztunnel without deploying L7 waypoints, avoiding exposure to potential HTTP vulnerabilities in Envoy. Envoy sidecars, on the other hand, always include full proxy capabilities.
Isolated credentials
Ambient's design physically separates credentials from application pods entirely. Certificates and keys are managed by the node-level ztunnel proxy, not in application pods, preventing potential credential access if a workload is compromised. If a pod's application is breached via a code injection flaw, ambient's ztunnel ensures no mesh keys are accessible, while a sidecar's in-pod Envoy could leak certificates, enabling attacker impersonation.
Improved mTLS enforcement
Ambient maintains full Istio security features, including mutual TLS for encrypted communication and L4 authorization by default, with L7 authorization available via waypoints. It enforces zero-trust by treating the ztunnel as hardened node infrastructure (similar to kube-proxy), ensuring traffic is routed securely without relying on per-pod proxies. This setup reduces the potential for man-in-the-middle attacks or unauthorized access that could exploit sidecar misconfigurations.
Operational simplicity
In ambient mode, upgrades and management are streamlined: ztunnel updates align with node patching, and waypoints can be upgraded transparently without pod restarts—reducing the complexity that often leads to security oversights in sidecar deployments.
Simplified egress configuration
In ambient mesh, egress control is more robust and easier to secure (see Controlling mesh egress). Configuring egress in sidecar mode is complex, increasing the chance of errors that expose vulnerabilities, such as unintended external access or unencrypted traffic. ztunnel secures egress with mutual TLS by default for mesh-internal hops, while waypoints support TLS origination for external destinations, ensuring that traffic leaving the cluster is encrypted.
Performance-driven security
Ambient's lower resource footprint enhances resilience to traffic spikes, maintaining security enforcement under load. During a DoS attack, ambient's ztunnel handles high traffic with mTLS intact, while sidecars might exhaust CPU, delaying authorization checks and risking breaches. Resource starvation (for example, high CPU/memory exhaustion from traffic floods) can impair a system's ability to enforce security policies consistently, as the proxies handling those policies (like mTLS encryption or authorization checks) may become overwhelmed, leading to delays, dropped connections, or partial bypasses.
Summary
Istio's evolution, in the form of the new ambient mesh, continues to improve upon the security posture of a microservices architecture.
Not only are all of the security benefits of sidecar mode retained, but ambient's more efficient and streamlined design addresses several security gaps inherent in sidecar mode through better isolation, reduced attack surfaces, and operational simplicity.
Learn more about ambient mesh and security:
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
