Traditional network security relies on a strong defensive perimeter around a trusted internal network to keep bad actors out and sensitive data in. In an increasingly complex networking environment, maintaining a robust perimeter is increasingly difficult.
Zero Trust security is emerging as a preferred approach for enterprises to secure both their traditional and modern, cloud-native applications. Zero Trust network architecture inverts the assumptions of perimeter security. In a Zero Trust network, every resource is protected internally as if it were exposed to the open internet.
To establish Zero Trust security guidelines for industry and the U.S. federal government, the National Institute of Standards and Technology (NIST) establishes Zero Trust security guidelines in a series of publications starting with SP 800-207 on Zero Trust architecture in general and its companion SP 800-204 series on security standards for microservices.
For an overview of Zero Trust security, see our article on Zero Trust principles and benefits. In this article, we’ll cover the Kubernetes and Istio reference architecture NIST recommends to apply Zero Trust principles in practice.
How to Implement Zero Trust Security in Kubernetes with Istio: a Reference Architecture for Modern Microservices Applications
As a companion to NIST’s standards for Zero Trust architecture in general, NIST has also published standards for how to apply Zero Trust principles specifically to microservices applications. Those standards, co-written by Tetrate founding engineer Zack Butcher, are codified in NIST’s SP 800-204 series.
In the standard, NIST establishes a reference platform consisting of Kubernetes for orchestration and resource management with the Istio service mesh to provide the core security features.
Kubernetes Security Gaps
As Kubernetes is primarily focused on orchestration, resource management, and basic connectivity, it leaves Zero Trust networking security concerns to be addressed by other parties. The main networking security gaps in Kubernetes are (NIST SP 800-204B, §2.1.1):
- Insecure communications by default
- Lack of a built-in certificate management mechanism needed to enforce TLS between pods
- Lack of an identity and access management mechanism
- Firewall policy that operates at OSI L3, but not L7 and, therefore, unable to peek into data packets or to make metadata-driven decisions
Service Mesh Fills Kubernetes Security Gaps: the Security Kernel for Microservices Applications
To augment Kubernetes for security, Istio acts as a security kernel in the NIST reference architecture. Istio satisfies the three requirements of a reference monitor (NIST SP 800-204B, §5.1). Istio is:
- Non-bypassable
- Protected from modification
- Verified and tested to be correct
The Envoy data plane provides reference monitors by way of non-bypassable policy enforcement points (PEPs) in front of each service and at each ingress and egress gateway. The service mesh code is independent of the application so its lifecycle can be managed independently and it can’t be modified at runtime. And, the mesh is a tightly controlled element of the system that can be hardened with more eyes and closer inspection (NIST SP 800-204B, §5.1).
And, as a dedicated infrastructure layer, Istio offers:
- A unified way to address cross-cutting application concerns;
- Standard plugins to quickly address those concerns and a framework for building custom plugins;
- Simplification of operational complexity;
- Easy governance of third-party developers and integrators;
- Cost reduction for development and operations.
Next Steps
To learn more about how to implement Zero Trust architecture, from a co-author of the federal security standards, read Zack Butcher’s Zero Trust Architecture white paper.
For an in-depth guide to NIST’s security recommendations and how Tetrate can help you implement the standard, check out Tetrate’s Guide to Federal Security Requirements for Microservices.
If you’re looking for the fastest way to get to production with Istio, check out our open source Tetrate Istio Distro (TID). TID is a vetted, upstream distribution of Istio—a hardened image of Istio with continued support that is simpler to install, manage, and upgrade. For organizations operating in a federal regulatory environment, Tetrate Istio Distro is the only distribution of Istio with FIPS-verified builds available.
If you need a unified and consistent way to secure and manage services across a fleet of applications, check out Tetrate Service Bridge (TSB), our comprehensive edge-to-workload application connectivity platform built on Istio and Envoy.