From buzzword to blueprint: Implementing zero trust on Red Hat OpenShift with the Layered Zero Trust Validated Pattern

Part 4 of a series on implementing zero trust security in Red Hat OpenShift with the Layered Zero Trust Validated Pattern.

Zero trust is easy to describe. The hard part is making it repeatable.

Zero trust is often described succinctly in a memorable sentence: never trust, always verify. The principle is sound and easy enough to describe, but that short sentence does not explain the hard parts: what a platform team should deploy on Monday morning, how a security architect should connect controls across a Kubernetes environment, or how a compliance officer can show that those controls are working.

That implementation gap is where the Layered Zero Trust Validated Pattern (ZTVP) provides its true value.

In the 1st article in this series, we looked at network policies as a last line of defense when an organization cannot patch fast enough. We showed how a default-deny posture and explicit ingress and egress rules can limit lateral movement and contain the blast radius of a compromised workload. In the 2nd article, we explored Red Hat Advanced Cluster Security for Kubernetes as the active security brain that watches runtime behavior and can terminate suspicious workloads. The 3rd article focused on a lesson that is easy to miss: Declaring network policy intent is not the same as verifying that the policy works as intended on a live cluster. Each of these articles represents a step in a zero trust security journey, as illustrated in Figure 1.

Figure 1: Zero trust security journey for Red Hat OpenShift

The next question is broader: What does a user actually get when those ideas are assembled into a deployable architecture?

The answer is not another security product; instead, it’s a pattern. The Layered Zero Trust Validated Pattern is an open, GitOps-managed implementation of coordinated zero trust capabilities for Red Hat OpenShift. It provides a tested starting point, shows how the components interact, and gives platform and security teams concrete user journeys that they can adapt to their own applications.

Zero trust is an architecture, not a checkbox

NIST SP 800-207 defines zero trust around a fundamental change in assumption from traditional security architectures: no implicit trust is granted to an asset or user account simply because of its location or ownership. Authentication and authorization are performed before access, and access is continually evaluated in context.

For a cloud-native application, this means there is no single gate at the edge that can implement the whole security model. A user accessing an application, a workload calling a database, a pipeline publishing an image, and an administrator changing a policy are all participating in different types of transactions. Each type needs:

• Identity: The identity of the person, service account, or even an agent taking action.
• Decision: Whether or not to allow requested action.
• Enforcement point: The place where decisions can be effectively enforced.
• Evidence: The evidence of what decision was taken for the requested action and how it was enforced.

ZTVP turns that architecture into a set of cooperating layers. It uses Red Hat OpenShift GitOps and the Validated Patterns framework to deploy and reconcile the components, so the environment is represented as code and can be reviewed, changed, and restored through a familiar Git workflow.

This matters to end users because the pattern removes much of the integration work that normally stands between a security design and a working demonstration. Not every organization needs to deploy every component. But the relationships between identity, secrets, transport, network boundaries, runtime monitoring, compliance scanning, and software supply chain controls are visible and reproducible, and that is where the value of the pattern lies.

The ZTVP layered model

The pattern is organized into 3 decoupled layers, as illustrated in Table 1. Each layer builds on the one below it, but feature sets and use cases can be selected according to the organization’s needs.

Table 1: The layers of the ZTVP model

To understand how these capabilities operate, let's first inspect the foundational layer that supports the entire architecture.

Layer 0: Foundation

The foundation establishes the baseline that every deployment can use. It includes:

• Red Hat build of Keycloak for user authentication and single sign-on through OpenID Connect (OIDC).
• Zero trust workload identity manager, based on Secure Production Identity Framework for Everyone (SPIFFE) and SPIFFE Runtime Environment (SPIRE), for short-lived cryptographic identities for workloads.
• HashiCorp Vault and the external secrets operator for Red Hat OpenShift for centralized and just-in-time secret delivery.
• The cert-manager operator for Red Hat OpenShift for certificate lifecycle management and encrypted communications.
• Red Hat Advanced Cluster Security for Kubernetes for runtime monitoring, threat detection, and response.
• Red Hat Advanced Cluster Management for centralized policy and multi-cluster management scenarios.
• The compliance operator for continuous scanning and remediation against available security profiles.

The foundation is the important shift from isolated tools to a security control loop. A workload can prove who or what it is, retrieve only the secret it needs, communicate over protected channels, operate inside a restricted network boundary, and generate runtime and compliance evidence.

Red Hat build of Keycloak is installed by default as an OIDC provider for identity and access management. The Layered Zero Trust Validated Pattern also supports other OIDC providers, such as Azure Entra ID.

Layer 1: Feature sets

Feature sets extend the foundation to meet a particular operational requirement. For instance, supply-chain capabilities can add Red Hat Quay, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer, and Red Hat OpenShift Pipelines. The network observability operator can add flow visibility through Loki and FlowCollector.

This is the practical benefit of the layered design: an organization can begin with a more secure platform baseline and then enable capabilities as its use cases mature. A team does not have to solve workload identity, application data protection, image provenance, and network analytics as one indivisible project.

ZTVP use cases

The current pattern documentation offers a number of use cases, including zero trust data protection, secure supply chain, and secure supply chain – automated approach. These can help you understand how this architecture works in practice. These use cases are not toy diagrams; they show transactions between actors and resources and connect those transactions to concrete enforcement points. Each use case or combination of them can cover various user journeys. Let’s take a look at some of the most typical and interesting ones.

User journey 1: Protect application data without putting security logic in the application

Imagine a platform engineer responsible for a business application with a web frontend and a PostgreSQL database. The application needs user authentication, database credentials, and network access to a small number of services. Traditionally, those requirements often become application code, long-lived Kubernetes Secrets, and a collection of broad network rules.

In the ZTVP data-protection use case, the demo qtodo application demonstrates a different flow. A user authenticates through the Red Hat build of Keycloak. The application is deployed with sidecars that handle workload identity and secret retrieval. The PostgreSQL database is in a separate namespace, and its access is limited by explicit network policy.

When the pod starts, SPIRE attests the workload and issues a SPIFFE identity. The sidecar uses that identity to authenticate to Vault. Vault returns the database credential appropriate for that workload and context. The application receives what it needs without a long-lived database password being embedded in its image; instead, the password is stored within the platform (as a Kubernetes Secret, for example) or committed to a Git repository.

The sidecar pattern separates security concerns from business logic. Authentication, mTLS, credential retrieval, auditing, and policy enforcement can evolve without requiring every development team to implement those functions consistently in every service. The tradeoff is an additional operational component in the pod, but the security behavior becomes more centralized and reviewable.

Network policy completes the journey. A namespace-wide default-deny policy removes implicit connectivity. Explicit rules allow the application to reach PostgreSQL and required platform services, while egress to unrelated namespaces, the Kubernetes API, or the public internet remains blocked unless justified. If an application pod is compromised, the attacker has fewer paths for reconnaissance, lateral movement, and exfiltration.

For the platform engineer, the result is a working reference for implementing a common requirement: protect sensitive data while minimizing application changes. For the security architect, the journey demonstrates identity-aware access, least privilege, segmentation, and defense in depth. For the developer, the security controls are available through the platform rather than becoming a bespoke feature of the application.

User journey 2: Establish trust from source to running workload

The 2nd journey is for a security architect or software supply-chain owner. People in these roles face a challenge broader than determining if an image contains a known vulnerability. They must also be able to establish where the artifact came from, what it contains, whether it was analyzed, and whether the cluster should accept it.

The secure supply chain use case connects those decisions. OpenShift Pipelines can build the artifact. Trusted Artifact Signer can sign it using a keyless workflow, reducing the burden of distributing and protecting long-lived signing keys. Trusted Profile Analyzer can store and analyze software bills of materials (SBOMs) and cross-reference components with vulnerabilities and advisories. Red Hat Quay (which is an optional OCI registry in ZTVP) provides a private registry for the resulting images.

The trust chain can therefore be expressed as a sequence: a change at the source, controlled build, SBOM generation, vulnerability analysis, artifact signing, signature verification, and deployment. In the automated supply chain use case, Tekton (implemented as OpenShift Pipelines in ZTVP) automates this sequence so that verification is part of the delivery path instead of a manual activity performed after deployment.

None of this can ensure that every vulnerability will be found or that a signed image is automatically safe. It establishes stronger provenance and decision points. A signature answers “Was this artifact produced by a trusted process?” An SBOM and vulnerability analysis help answer “What is in it and what is known about those components?” Policy determines whether that artifact is acceptable for a particular environment.

User journey 3: Turn security configuration into evidence

The 3rd journey is for the compliance officer and the teams who must explain the platform to auditors. A zero trust architecture is not credible merely because its components are installed. Teams need evidence that controls are configured, changes are governed, and important behavior is visible.

ZTVP helps by making the deployment GitOps-managed. The desired state is saved and reviewed in Git, reconciled by OpenShift GitOps, and visible as a history of changes. The compliance operator continuously scans the cluster against supported profiles and can support remediation. Red Hat Advanced Cluster Security provides runtime findings and security policy visibility. Network flow observation and the verification practices described in the 3rd article in this series help compare intended communication with observed communication.

The evidence produced by these tools is not a replacement for an organization’s governance process. It is a more useful starting point than a 1-time screenshot or a manually assembled spreadsheet. The platform team can show what was deployed, the security team can show what was detected and blocked, and the compliance team can connect implementation evidence to its control narrative.

What frameworks does the default deployment support?

A default deployment of ZTVP supports alignment and evidence; it does not automatically certify an organization against a framework, satisfy every control, or make a cluster FedRAMP-authorized. Framework requirements also depend on scope, configuration, organizational processes, and the specific deployment variant.

The default foundation provides a meaningful baseline for the frameworks outlined in Table 2.

Table 2: How ZTVP addresses various frameworks

It’s important to distinguish between default and optional capabilities of ZTVP. Identity, secrets, certificates, runtime monitoring, compliance scanning, and network boundaries are part of the foundation described by the pattern. Private registry, artifact signing, SBOM analysis, and automated pipelines are feature-set capabilities used by the secure supply chain use case. An organization should map its selected ZTVP variant to its own system security plan and control inheritance model.

For the complete per-capability breakdown with detailed descriptions, see the ZTVP capability-to-framework mapping on the project’s GitHub.

From reference architecture to adoption path

ZTVP is designed to support incremental adoption. A team can begin by deploying the foundation and using the data protection use case to understand workload identity, dynamic secrets, and microsegmentation. It can then add runtime policies and network observability as it learns which flows are expected. The supply-chain feature set can follow when the organization is ready to enforce provenance and SBOM-based decisions.

The most productive implementation loop remains the one established in the previous article in this series:

1. Design the transaction and identify its actor, resource, context, and policy.
2. Test the policy on a live cluster and verify that required flows still work.
3. Deploy the verified state through Red Hat OpenShift GitOps.
4. Observe runtime behavior, compliance findings, and network flows.
5. Iterate when the application, platform, or threat model changes.

That loop is the real end-user outcome of ZTVP. It gives platform engineers deployable building blocks, security architects a concrete architecture to evaluate, and compliance teams an evidence path to develop. It also makes the gaps visible: a capability that has not been enabled, a policy that has not been tested, or a control that still requires an organizational process.

Getting started

The Layered Zero Trust Validated Pattern is available through the Validated Patterns project and its source repository. The current getting-started documentation describes the Red Hat OpenShift prerequisites, GitOps deployment, configuration variants, and verification steps.

Start with one user journey rather than a list of products. Protect one application and its data, trace one software artifact from source to deployment, or take one compliance requirement and identify the evidence that the platform can produce. Then, use the layered architecture to add the next capability without losing the relationships established in the foundation.

Zero trust becomes practical when the policy is explicit, the enforcement point is real, the result is observable, and the process is repeatable. ZTVP provides that starting point for Red Hat OpenShift—and a path for turning zero trust from an architectural ambition into an operating practice.

References

• Layered Zero Trust Validated Pattern
• ZTVP architecture
• ZTVP getting started
• NIST SP 800-207 Zero Trust Architecture
• CISA Zero Trust Maturity Model
• Earlier blog posts in this series:
  • Part 1: “Can't patch fast enough? Zero trust as a last line of defense”
  • Part 2: “Lights on! Real-time threat response with Red Hat Advanced Cluster Security”
  • Part 3: “Closing the loop: From network policy intent to verified realityPágina disponible en Inglés (Español no está disponible)”