It wasn't long ago when the systems we built were a far cry from the ideal in terms of their security posture. Security concerns were an added burden on application development teams whose focus was oftentimes more on application logic. Applying security-related policy at the application level had many disadvantages. Security was not applied uniformly across all applications, and reconfiguring aspects of security required at the very least restarting applications, at worst building and publishing new artifacts. Systems that haven't embraced service meshes likely still live in that world.
The model for security in distributed systems environments relied on the concept of perimeter security, where the focus was on ensuring that attackers couldn't penetrate a system. Internally within the system, microservices freely communicated with one another in plain text, blindly trusting one another. These walled gardens were fragile arrangements susceptible to exploitation.
In the days where an enterprise infrastructure was entirely on premise, the notion of a perimeter defense might have still made sense. But the notion of a perimeter defense increasingly falls apart in today's multi-cloud world. Can we even draw a circle around all of our deployed software components?
Separately, perimeter-security often has no alternative but to base its security decisions on IP addresses. The fundamental problem is a lack of network identity, as John Howard's NetworkPolicy: the wrong solution to the right problem makes clear.
Istio’s Security
The Istio project addresses these security issues head-on: it solves the problem of network identity, by assigning all workloads a SPIFFE ID based on an issued X.509 certificate.
But just as importantly, the process of obtaining and communicating the workload identities is entirely automated, meaning that no additional burden is placed on engineering teams to begin deriving the benefits of network identity.
When workloads communicate with one another, the sidecar proxies use the associated certificate to establish a mutual TLS (mTLS) handshake. Suddenly all communication between services uses strong encryption, and the identities of caller and callee are known. This process is completely transparent to applications, and again implies no "cost" or overhead on the part of application teams.
We suddenly can realize a zero trust architecture, one where the notion of perimeter defense is no longer necessary. Zero trust is based on the assumption that an attacker is already inside your network. In an environment where the attacker has to supply a network identity in order to communicate with any software component, they suddenly find themselves sandboxed, and lose the ability to do harm.
In Istio, mutual TLS (mTLS) - encrypting and authenticating all communication between services - provides for robust security.
This capability was introduced in Istio with sidecars.
Security with Ambient Mesh
It is worthwhile asking the question: How does Istio's ambient mesh alter the security picture, and does it produce a more robust security posture?
In ambient mesh, we no longer have sidecars. Ambient introduces the zero-trust layer 4 tunnel, also known as ztunnel, deployed as a DaemonSet. It is the ztunnel component that manages the identities on behalf of the workloads it proxies. The communication between workloads traverse these ztunnel proxies, who ensure that these certificates are utilized to establish mutual TLS.
In sidecar mode, although application logic was no longer coupled to these concerns due to the proxy representing an out-of-process solution, coupling still existed in terms of the sidecar being co-located inside the workload's pod.
Ambient mesh eliminates that last aspect of coupling.
From a security standpoint, the sidecar represents an increased attack surface: Each sidecar introduces another component that needs to be secured and patched. Imagine the inconvenience of having to roll out a restart of all your workloads to effectively patch their sidecars.
In summary, ambient provides stronger security by default via automatic mTLS encryption, and authentication for all Layer 4 traffic, providing a robust security posture without extra effort.
Authorization
The benefits of strong identity don't stop at encryption of communication traffic.
First and foremost strong identity provides a means of authentication of workloads: services know the identity of their peer workload. This is in my opinion a game changer. Clients with no identity or with an invalid identity cannot participate - they cannot establish connections to other workloads. This takes place in a layer below the application logic, meaning that there's no code coupling, i.e. this is not a concern of the application developer.
Authentication becomes the foundation for authorization. Istio provides the AuthorizationPolicy resource to describe rules for authorization. The provenance of the request (e.g. what namespace the client resides in), the identities of the calling workloads, or the identities of the end users (based on JWT tokens present in HTTP headers) can become conditions for access to an endpoint.
Security At the Edges
At ingress of course we have a gateway that acts as a policy enforcement point for all traffic coming into the mesh. We configure ingress to enforce TLS-based communication with external clients. For user authentication and authorization, we can configure ingress using standards-based authentication and authorization mechanisms such as OpenID Connect (OIDC).
Egress gateways play the same role for traffic exiting the mesh. Istio supports routing of external requests through egress gateways. We can monitor and audit traffic leaving the cluster as it passes through the egress gateway.
We can control the mode of communication to external clients (e.g. simple TLS). and we can overlay an authorization policy on top of it. We can restrict which clients are permitted to call out to which specific external services. We can be as detailed as necessary, for example, to authorize calls to specific endpoints based on path (path prefix, or regex), query parameters, HTTP method, etc..
Security policies can be applied directly at the platform level, and are in no way coupled to the application logic of your microservices. Gone are the days of entangled concerns of security and application logic. The flexibility of being able to specify or alter security policies at any time without having to rewrite, rebuild or redeploy code gives us increased agility, and the ability to respond to situations quickly and unintrusively.
A Stronger, Simpler Path to Zero Trust
As cloud-native environments grow more complex and dynamic, the need for robust, scalable, and decoupled security becomes non-negotiable. By embracing Istio's evolution through ambient mesh, platform teams can achieve zero-trust with minimal friction, automating identity, encryption, and policy enforcement at scale. Learn more here:
%20For%20More%20Dependable%20Humans.png)
