Layered Zero Trust
SandboxAbout the Layered Zero Trust pattern
Zero trust is an approach to security architecture based on the idea that every interaction starts in an untrusted state. The Layered Zero Trust pattern shows how to implement zero trust in a Red Hat OpenShift Container Platform environment. The pattern identifies specific transactions between an actor and a resource. For these transactions, you can determine the context and enforce policies.
Because of the breadth and diversity of possible interactions between components in Red Hat OpenShift Container Platform, this pattern is presented as a set of abstract, stackable layers. These layers provide the prerequisite capabilities that are needed to implement appropriate enforcement points. For each instance, this pattern describes the associated actors, transactions, and the zero-trust policy that you can implement within the platform. To provide context for users, this pattern uses relevant business use cases and traces them to the associated implementation components.
- Use case
The pattern addresses the shortcomings of traditional cybersecurity methods, such as defensive hardening and reactive detection. It is particularly effective for the following types of systems and environments:
Distributed systems, such as cloud and edge environments.
Autonomous and artificial intelligence (AI) or machine learning (ML) based systems, including robotic process automation.
Large, composite systems that integrate third-party or legacy components.
This pattern provides specific implementations for each of these business use cases within its abstract, layered structure.
- Background
Traditional security approaches are often incomplete, as they are susceptible to unknown exploits (zero-days) and rely on human-intensive processes that can be inconsistent and prone to error. Attackers continuously develop new methods to evade signature-based detection and exploit systems by targeting those already deemed trustworthy.
In contrast, the Zero Trust architecture operates from the assumption that a breach will occur. It focuses on preventing further compromise by establishing well-defined security boundaries and enforcing a deny-all default access control stance. The pattern emphasizes significant automation and grants access dynamically, based on policies, with a least-privilege, as-needed approach. Instead of relying on signatures, it explicitly enumerates allowed actors and monitors their behavior, which is a more effective way to contain malicious activity. Zero Trust architectures incorporate contextual information and user behavior analytics to inform access decisions, proactively preventing lateral movement in case of a compromise.
About the solution
The Layered Zero Trust pattern implements a layered zero trust architecture that shows workload identity management, secure communication, and secret management capabilities.
The solution integrates many Red Hat components to offer:
Workload identity using Secure Production Identity Framework for Everyone (SPIFFE) and SPIFFE Runtime Environment (SPIRE) standards.
Secure secret management through HashiCorp Vault.
Identity and access management by using the Red Hat build of Keycloak (RHBK).
Certificate management for secure communications.
External secret management integration.
Architecture
The Layered Zero Trust pattern architecture consists of many components that work together to offer a secure environment for applications and workloads.
The pattern consists of the following key components:
Zero Trust Workload Identity Manager: Implements workload identity using SPIFFE/SPIRE.
HashiCorp Vault: Provides secure secret storage and management.
Red Hat build of Keycloak (RHBK): Manages identity and access for users and services.
OpenShift Cert Manager: Manages the lifecycle of certificates for secure communication.
External Secrets Operator: Synchronizes secrets from external systems into the cluster.
QTodo application: Serves as a Quarkus-based application to show zero trust principles.
PostgreSQL database: Provides the backend database for the demonstration application.
Sidecar pattern
The sidecar pattern is a deployment model where a separate container or process, known as a sidecar, runs alongside the main application to handle auxiliary tasks. In an OpenShift Container Platform environment, pods simplify this by ensuring the sidecar and main application share the same lifecycle. This approach benefits Zero Trust architectures by enabling centralized enforcement of security policies such as authentication, authorization, traffic encryption (mTLS), rate limiting, auditing, and logging, without requiring developers to add this logic to every microservice. It separates concerns, simplifies development, and allows security policies to be updated independently of the main application.
While sidecars are often criticized for adding complexity and resource usage, these are often misconceptions:
Complexity: Sidecars simplify the main application by offloading tasks, and modern platforms, such as OpenShift Container Platform, are designed to manage them efficiently.
Resource Usage: The resource cost of a sidecar is often minimal compared to the additional CPU and memory required to integrate security logic into every application.
Debugging: Sidecars can simplify debugging by isolating logs and metrics from the main application, making it easier to pinpoint the source of a policy failure.
The Layered Zero Trust pattern uses the sidecar approach to offload critical security functions from the main application. This centralizes policy enforcement, simplifies development, and separates security concerns. The sidecar patterns in this approach handle tasks such as authentication and authorization, traffic encryption, rate limiting, and auditing and logging.
About the technology
The following technologies are used in this solution:
Zero Trust Workload Identity Manager: Implements workload identity using SPIFFE/SPIRE.
HashiCorp Vault: Provides secure secret storage and management.
Red Hat build of Keycloak (RHBK): Manages identity and access for users and services.
Red Hat OpenShift GitOps: A GitOps continuous delivery (CD) solution based on ArgoCD
OpenShift Cert Manager: Manages the lifecycle of certificates for secure communication.
External Secrets Operator: Synchronizes secrets from external systems into the cluster.
Compliance Operator: Provides ability to scan and remediate cluster hardening based on profiles
QTodo application: Serves as a sample Quarkus-based application to show zero trust principles.
PostgreSQL database: Provides the backend database for the demonstration application.
