Zero Trust has become increasingly relevant to organisations due to the distributed architectures of modern applications - web-based, cloud-hosted and API-reliant - and the distributed nature of the workforce accessing them.

It differs from traditional perimeter-based approaches to security, which are more analogous to security screening at the airport - where, after passing security checks, you can access any number of resources that either airlines or the airport provide. Under a perimeter-based model or security approach, a 'trusted zone' for applications, users and traffic is established beyond the perimeter check.

The challenge for organisations is that even with a secure perimeter, internal systems and data can be compromised if a malicious actor gets in or another internal system has a vulnerability. Attackers have become increasingly successful in getting beyond the perimeter into the 'trusted zone' and abusing the privileges available inside that zone.

Recent security violations, in Australia and regionally, have seen attackers use stolen credentials to access this 'trusted zone' and steal and publish confidential and personally-identifiable information, with damaging consequences.

Perimeter-based security remains relevant today but needs to be augmented. Current best practice approaches to security push for the removal of trust from enterprise architectures altogether.

This is what's called the Zero Trust model.

The fundamental change is a move from a security setup where everything behind a security check is trusted, to a setup where nothing is trusted, and everything is verified by default.

Implementing Zero Trust

Zero Trust is a set of security principles that treats every component, service, user, or office system as if it's continuously exposed to potentially malicious players. It differs from perimeter-based security because a security boundary is created around each individual resource rather than around an entire group of resources.

Zero Trust has been talked about for several years. However, there are often surveys that point to nascent adoption and maturity. Part of the reason for that is the number of different approaches that can be taken to create a Zero Trust architecture and to achieve Zero Trust objectives.

One approach that application developers and operations teams are increasingly looking to is implementing Zero Trust principles through service mesh.

Service mesh is a set of software components that act as the 'glue' for a set of independent applications or microservices to communicate with each other. The goal of a mesh is to guarantee secure communications between each application (or each microservice that makes up a single application) and be able to redirect traffic in the event of failures.

At a simpler level, it's like a traffic navigation system that securely delivers messages between different components of a modern web-based or cloud-hosted application.

There is increasing overlap between what a service mesh provides and the technical components needed that make up a Zero Trust architecture. However, by default, basic open source distributions of meshes like Istio don't go far enough to deliver features needed for comprehensive security.

However, the addition of comprehensive security controls to service meshes, such as Gloo Mesh provided by Solo, are making them more well-suited as a vehicle to implement Zero Trust. In addition, emerging mesh architectures, specifically Istio Ambient Mesh, further increase the capability of service mesh to underpin a complete or mature implementation of Zero Trust.

Mesh capability alignment

To implement Zero Trust using service mesh, one must understand how the principles of Zero Trust align with components of a Zero Trust architecture and how these align with the service mesh's current and emerging capabilities.

Identity is a core component of Zero Trust. Everything is a resource, and every resource is given an identity that has to be verified before access is granted. Identity verification in current-state environments is carried out using corporate SSO. Future state environments will utilise cloud-based identity; through the use of SPIRE - an implementation of the Secure Production Identity Framework for Everyone (SPIFFE) - and external authentication (ext_auth) that delegates authentication to a verified identity management platform, a service mesh can be used to implement cloud-based identity verification and delivery.

Other key components of Zero Trust are access control, resource protection, policy and orchestration, and monitoring and analytics. All of these capabilities can be implemented using either a network-based or sidecar proxy. Architecturally, service meshes are sets of lightweight network proxies, typically deployed alongside application code in a "sidecar container". They handle functions such as communication between microservices, service discovery, load balancing, authentication and authorisation, and observability.

This means that many components of Zero Trust can be achieved using a service mesh. By default, service mesh provides policies that can be centralised from a management point of view but distributed from an implementation point of view. In addition, monitoring and analytics is done in a service mesh without anyone having to do anything. The sidecar proxy model automatically collects and starts providing data into monitoring platforms without any of the developers or platform engineers having to build anything for it.

As service mesh architectures continue to evolve, more enterprises and government agencies will use them as an enabler for improved cybersecurity protections through the implementation of Zero Trust.