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.
Here are NIST’s core zero trust architecture principles and the Kubernetes and Istio reference architecture recommended to apply them in practice.
The Six Principles of Zero Trust Networking
All communication should be secure, regardless of network location. Network location and reachability do not imply trust. Access requests inside an enterprise-owned or other private network must meet the same security requirements as communication from any other location. A rubric for a zero trust system is that you could expose it to the open internet and it would still be secure, with no unauthorized access to systems, data, or communication.
All communication should be encrypted. Encryption on the wire prevents eavesdropping and also ensures messages are authentic and unaltered. This implies implementing at least TLS for all communication, with mTLS and associated secure workload identities as a best practice for service-to-service communication.
Access to every resource should be authenticated and authorized based on dynamic policy. Service identity and end-user credentials are dynamically authenticated and authorized before any access is allowed. The dynamic context of the access request should be part of the access decision. This may include behavioral attributes like deviations from observed usage patterns or the state of the requesting asset like software versions installed, network location, and time/date of the request. When access is granted, it should be granted with the least privilege required.
Access to resources should be bounded in space. The perimeter of trust around resources should be as small as possible—ideally zero. Access should be mediated by a policy enforcement point (PEP) in front of every resource that is capable of retrieving and enforcing access decisions. This should apply to all inbound, outbound, and service-to-service access.
Access to resources should be bounded in time. Authentication and authorization are bound to a short-lived session after which they must be re-established. This ensures that access decisions are made frequently and with the most recent context available.
Access to resources should be observable. As much information as possible should be collected and used to improve security posture. This allows the integrity and security posture of all assets to be continuously monitored and policy enforcement continuously assured. Also, insights gained from observing should be fed back to improve policy.
Why Zero Trust Security Is Better
Network reachability is not authorization. Unlike perimeter security, access to a service is not granted solely because that service is reachable. It must be explicitly authenticated and authorized as well.
Limited blast radius of perimeter breaches prevents lateral movement by attackers. Authenticated and authorized workloads are protected from perimeter breaches. Bounding in time limits the risk of compromised credentials.
Fine-grained policy. Bounding in space allows for high granularity of policy enforcement.
Frequent policy evaluation. Bounding in time with dynamic policy enforcement on short-lived sessions ensures authorization is based on up-to-date policy.
Secure, authentic communication. Encryption and strong workload identity limits reconnaissance and provides for authenticity of communication.
Real-time and auditable assurance of security posture and regulatory compliance. Fine-grained observability allows real-time assurance and post-facto auditability of policy enforcement plus the necessary data for troubleshooting and analysis.
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.
