At the joint NIST-Tetrate conference this year on ZTA and DevSecOps for Cloud Native Applications, Tetrate founding engineer Zack Butcher offered a deep dive into new publications in the NIST SP 800-204 series that sets the standards on security for the use of microservices architecture for the US Government. In this article, we’ll provide a brief overview of Zack’s talk, with a link to a full recording for all the details.
Service Mesh Solves Application Challenges
Modern application deployments face two dueling challenges. On the one hand, the migration to modern distributed architectures makes it more difficult to connect, manage, secure, and monitor applications. Decomposition into microservices means there are many more moving parts to manage. And increasing adoption of cloud-based infrastructure means that the moving parts are distributed across heterogeneous environments.
The US Government has endorsed adopting zero trust architecture (ZTA) as a critical step to address these challenges. ZTA shrinks the perimeter for security, moving the trust boundary from networks and gateways down to the application itself. The National Institute of Standards and Technology (NIST) has recommended using a service mesh as the preferred way to implement zero trust architecture for microservices-based applications. Service mesh is a dedicated infrastructure layer specifically designed to connect, monitor, manage, and secure services, where it also serves as a new security kernel. This new infrastructure layer—as an agent of cross-cutting change—makes it possible to consistently implement zero trust principles and connect, monitor, and manage services across distributed, heterogeneous environments.
Service Mesh in 60 Seconds: Facilitating Migration to Modern Distributed Architectures
As a dedicated infrastructure layer for cross-cutting concerns, service mesh facilitates the migration to modern distributed architectures along four key vectors: security, connectivity, observability, and reliability.
Service mesh facilitates connection of application components with service discovery and resiliency features like load balancing, retries, and circuit breakers. It facilitates traffic flow by offering universal points in the data plane to implement traffic routing and security policy. And service mesh does all this at L7 in the OSI model, not just at the connection level. Service mesh also provides security tools like workload identity to facilitate encryption in transit with mTLS and service-to-service authorization. Finally, service mesh provides tools to understand the system, to be able to assert system state, and to report back compliance.
In Istio, the reference implementation from the NIST SP 800-204 series, the service mesh is composed of a data plane and a control plane. Instances of the lightweight and extensible Envoy proxy are deployed as sidecars to each service and at ingress and egress gateways. These Envoy instances comprise the data plane, where they mediate all L7 requests between each service as well as between each service and the outside world. The Istio control plane, an instance of istiod, configures the data plane, offering runtime control of the data plane.
Service Mesh for Zero Trust: Shrink the Perimeter with a New Security Kernel
The Envoy data plane—with Envoy proxies deployed as sidecars, and at ingress and egress—gives us an L7 policy enforcement point (PEP) everywhere across the system. At each Envoy PEP, we have an opportunity to apply policy to all communication in the data plane. This forms what’s referred to in the classic security literature as a reference monitor: a reference validation mechanism that enforces an access control policy over all subjects and objects, is tamperproof, always invoked, and small enough to be subject to analysis and testing. The completeness of the reference monitor can be assured (NIST SP 800-53, AC-25). Having a reference monitor between every subject and object effectively shrinks the trust boundary to as near zero as practicable.
Envoy is also highly extensible with custom extensions, WASM, Lua, and the like. In a service mesh, this extensibility mated to Envoy’s ubiquity as a universal PEP offers the ability to implement whatever policy we need.
What’s left is to stitch the individual proxies together into a coherent whole. That’s what the Istio control plane does. The control plane programs the Envoy instances comprising the data plane, giving us coherent operational control of the data plane at runtime. It also collects and records runtime data to make the system observable and lets us prove that the policies we intend are actually being enforced.
When we have universal, non-bypassable PEPs plus a control plane to configure all reference monitors, we can start to call this a new security kernel, another classic idea from the security literature. It’s effectively the heart of the security for your system. You can offload security concerns here, where the kernel can be heavily audited and controlled, instead of having those concerns spread across various libraries, embedded in application code, and in various black-box L3/L4 tooling. Pulling security concerns down into the platform layers also helps relieve application developers from the burdens of security concerns, increasing their agility.
The use of reference monitors and a security kernel is a long-accepted practice in operating systems. It’s exciting that we can realize this architectural pattern forward into modern architectures using a service mesh.
Watch the Presentation
For more detail and a deep dive into NIST’s security recommendations for microservices applications, watch the full presentation available on-demand at NIST.
