Using Service Mesh to Enable Zero-Trust Architecture (ZTA)
Cybersecurity is not only a threat to private enterprises, it’s a national government priority, too. A 2021 presidential executive order names zero-trust architecture (ZTA) as part of new cybersecurity initiatives across government agencies. To enact said mission, National Institute of Standards and Technology (NIST) reports now recommend the use of service mesh to enable next-generation access control systems across agencies.
I recently reconnected with Zack Butcher, founding engineer, Tetrate. As a co-author of the new NIST recommendations, Butcher has keen insight into securing containers and microservices using service mesh to construct a ZTA at scale. According to Butcher, new NIST documents not only serve as critical blueprints for government agencies but will likely inspire further adoption of service mesh throughout the private sector.
4 Pillars Of Zero-Trust Architecture (ZTA)
Traditional security models are becoming increasingly irrelevant to today’s decoupled development. For an organization managing hundreds of cloud-based microservices, it becomes hard to trust traffic among and between all actors. Thus, we’re seeing the rise of a ‘trust no one’ approach, along with the need for a security architecture to fit this paradigm.
Yet, most organizations have an incomplete understanding of what it means to build a ZTA, says Butcher. Zero-trust involves the authentication and authorization of all actors, but a ZTA ecosystem requires a few more parts to function. “ZTA is much more than just encryption in transit,” Butcher explains. He outlines four broader pillars, of which all are necessary to achieve a ZTA.
1. The Pre-Runtime Piece
The system must ensure the security of the software’s provenance. This involves understanding the code going in and knowing what you’re deploying is stable. When working with decoupled microservices, understanding the entire software ecosystem is paramount to ensure supply chain security.
2. The Runtime Piece
Following pre-runtime, you need to ensure software security at runtime. This is where encryption in transit comes in. It is at this stage that the system must prove the authenticity of the message. One method to establish trust, Butcher says, is using mTLS with SPIFFE identities.
Note that a zero-trust system does not blindly assume any actor is working in good faith, no matter if it’s a human or microservice, or whether the communication is coming from internal or external sources. Authentication and authorization for application-to-application communication and authentication and authorization of end users are equally as important. This can be framed as follows:
- Service authentication
- Service authorization
- End user authentication
- End user authorization
Machines are no longer communicating with other machines behind traditional IT perimeters. In a system like Kubernetes, a single machine may hold many different applications. The need to secure service-to-service communication is a large impetus behind ZTA today, Butcher explains. In a ZTA environment, certificates are exchanged via mTLS, encoding the application itself.
But service-to-service communication is only one aspect. A ZTA “needs to ensure end-user credentials are present and being checked for every service,” says Butcher. Whereas authenticating end users at the API gateway is an old-school method, performing authentication and authorization on JSON web tokens (JWTs) related to users is a more modern approach. With this in place, “you can use service mesh to start to implement end user application resource authorization,” Butcher explains. Though this authorization level traditionally lives within the app, teams can delegate it to the mesh for more consistent control.
3. Continuous Assertion of State
In addition, ZTA requires some sort of polling system to continuously monitor system behaviors and metrics. Consistent verification is required to ensure the system is functional and secure and to prove that policies are still in effect, says Butcher. This would also bake in alerting to signal security teams when policies fail or when compliances are breached.
4. Governance
Lastly, a ZTA requires some form of governance to control who can apply and change policies. This is another reason why ZTA and service mesh fit so well together. Within a service mesh architecture, a control plane sits decoupled from the data plane, allowing operators to apply consistent features across application-level proxies.
US Government Embraces Zero-Trust Architecture
President Biden’s 2021 executive order marks the first U.S. government-mandated requirements for zero-trust architecture. To enact this within government, NIST is making significant strides toward standardizing government departments’ cybersecurity. The following two reports are part of a series of government guidelines intended to be followed by every government agency:
- S.P. 800-204A: Building Secure Microservices-based Applications Using Service Mesh Architecture explains the trend of decoupled microservices architecture and recommends service mesh as a means to apply consistent policies.
- SP 800-204B: Attribute-based Access Control for Microservices-based Applications using a Service Mesh provides specific guidance on adopting an attribute-based access control (ABAC)-based authorization framework for securing microservices-based applications using a service mesh.
Some standards and open source tools we expect to see government departments adopt include Istio, Envoy, JWTs, Mutual TLS, SPIFFE and OpenID Connect. The key factor is to allow granular controls at the system kernel level as part of the runtime security system, Butcher explains. He advocates for using Envoy as a runtime implementation point.
As an example in practice, the Department of Defense (DoD) is already using Istio for end-to-end encryption and authentication.
Future Industry Adoption
For now, these are strictly government mandates. But these reports could have ripple effects. Looking to the future, Butcher anticipates increased use of zero-trust service mesh architectures among health care, financial and other private sector verticals will follow. As the majority of microservices deployments already use service mesh, using it for ZTA could be the next logical step.
The best practices depicted by NIST help paint a more practical picture of what ZTA actually looks like. NIST reports could also help define a set of blueprints for other systems to mimic. Incumbents are currently working on “a general platform that can be reused across the government,” says Butcher. As agencies adopt ZTA, he expects to see similar platforms and blueprints pushed out across the industry as more patterns are adopted.
A strong U.S. cybersecurity commitment is one of those “rare opportunities where the government is leading the way,” says Butcher. In terms of implementing a ZTA, he adds that the onus will likely fall on commercial offerings to provide that holistic four-tiered ecosystem consisting of pre-runtime control, runtime controls, continuous assertions of state and administrative controls.