How to Create Zero Trust Architecture for Service Mesh
It’s not surprising that zero trust security has captured the imagination of tech organizations. The premise is beguilingly simple: just because you come into a system doesn’t mean you should have access to everything. Or, indeed, anything.
Each request — whether from a person or a microservice — is examined in a broader security context, taking into account attributes such as: Who is this user? How do we validate that? What time of day is it? What permissions does this user have?
Simple as the principle is, progress in implementing zero trust is proving elusive. Gartner predicts that it will be 2026 before even one in 10 large organizations “will have a mature and measurable zero trust program in place.” Less than 1% have such an implementation in place today.
The fact is, implementing a zero trust architecture requires a way to understand what applications are doing, and to manage their security properties, as Christian Posta, Solo.io’s global field chief technology officer, told The New Stack. And that can’t simply be bypassed by developers in a hurry or undermined by a pre-existing or new vulnerability.
This is where a service mesh like Istio comes into play, at least for modern applications built on microservices. The mesh operates as a visible infrastructure layer that can be added to applications, providing observability, traffic management and security. In the case of Istio, this is achieved using the Envoy sidecar, which acts as a proxy for each service, without having to be embedded in core application code.
Indeed, Posta said, the number one use case for service meshes is security. Perhaps that’s not surprising, given that the service mesh approach enables secure communication between the services that make up an application, as well as authentication and authorization, and traffic management.
But he pointed out, a service mesh “doesn’t just automatically and magically solve zero trust.” Rather, he said, “What a service mesh does is implement a lot of the properties that you would expect in a zero trust stance.”
And simply taking an open source project like Istio and dropping it into a real-world enterprise environment is not straightforward, he said: “Enterprises are not clean cut with nice, square edges for everything to fit in just perfectly. They’re war zones.”
New Mesh, Rough Edges
So, Solo.io, and other Istio contributors, have done a lot of work on “softening up” some of those rough edges, Posta said. “The products that we build here at Solo are meant to further simplify the effort of deploying, installing Istio, and manage service mesh in general.”
But even this doesn’t totally solve the complexity challenge when constructing a zero trust architecture — or of developers simply doing exactly what they want.
As Posta told The New Stack, developers may forget to deploy the sidecar within their applications. Or they may misconfigure ii. Or the sidecar may not be as transparent as the developers intend.
Sometimes companies will pursue policies or procedures that are initially incompatible with Istio. For instance, he said, one company Solo.io worked with relied on the HTTP headers between applications being case sensitive. But the HTTP spec doesn’t cover case sensitivity for headers. This meant Istio — still within the spec — changed them to lowercase. The result? The applications broke.
“So here’s an example of, as a developer, I wanted to deploy a sidecar because I want to be in the mesh,” Posta said. “But now I run into these unintended consequences because of some weird crazy things the enterprise is doing.”
At the same time, he pointed out, the Envoy proxy, which is used as the data plane in Istio, is extremely flexible. It can open connections, establish mutual TLS, and collect telemetry. It also understands database protocols, such as MongoDB and MySQL, and can be extended and customized with WebAssembly.
“And then its core is basically doing things around HTTP, and GPRC, request routing, load balancing, circuit breaking,” said Posta.
Looked at another way, this flexibility starts to look like complexity. But, if security is the key driver for implementing a service mesh, it probably makes sense to keep things as simple as possible, by removing the sidecar where appropriate.
This is the aim with Istio Ambient Mesh, introduced last year, which removes the sidecar, without trading off the security benefits of the service mesh. Instead, individual services are connected via Ztunnels — or zero trust tunnels — which handle layer four connectivity, while more detailed policy enforcement is handled at layer seven. Solo.io has announced support for Ambient in its own Gloo Mesh implementation.
Simply running a secure overlay, which Posta described as “the backbone of Ambient,” means engineers aren’t distracted by issues like case sensitivity or the nuances of how the proxy handles certain protocols. “We’re just solving the use case that you want, using just the amount of technology that you need,” he said. “And then the rest of that stuff is opt-in later if you need it.”
Casting the Mesh Wide
While the core Istio project is predominantly focused on Kubernetes with support for expanding out to virtual machines (VMs), Posta said Solo.io’s technology supports complex environments spanning multicluster, multi on-prem and public cloud and demilitarized zones (DMZs).
“We can integrate VMs and physical machines,” he said. “There’s a lot of complexity that comes into it. We try to shield people away from that. We integrate with things like [Amazon Web Services] Lambdas directly, that open source Istio doesn’t do. And, by going down that path, that also alleviates people from having to use AWS API Gateway and [application load balancers].”
Many organizations, particularly in the financial world, still use code written decades ago which can present a security and integration challenge.
But the service mesh is focused on enforcing policies over the network, Posta pointed out. “So if there are [Simple Object Access Protocol] applications, they can communicate over the network,” he said, which means Solo.io can apply “some level of policy.”
Ambient can potentially support more workloads and run in more places, because it is not a full-blown proxy. Deploying a sidecar on a VM can be “pretty invasive”, he said.
“We can maybe more easily include things like workloads that run on HashiCorp Nomad, or AWS ECS Fargate,” Posta said. Logically, he added, those places can extend all the way to mainframes.
This really does open up how service meshes can be used to enable zero trust architectures, even in that “war zone” of enterprises with legacy applications and infrastructure running alongside modern, Kubernetes-based, cloud native applications.
None of which means the sidecar will be completely obsolete. “At Solo, we believe that Ambient will eventually become the default data plane in Istio,” said Posta. “And the sidecar will be used as an optimization when needed.”
When that is needed will depend on the overall architecture and the security context in which the zero trust architecture is being implemented.
This means, said Posta, “The behavior of the mesh is going to be dictated by multiple different groups in the organization.”
This includes the platform engineering team, which typically owns the life cycle of the mesh, but also the security team, obviously, as well as site reliability engineering teams, API gateway teams, and of course the application owners.
Does this make life complex? Probably. Life is always more complicated when people are involved. This is another reason to make implementing the service mesh on which zero trust is built as uncomplicated as possible.
