Skip to content

Commit 6182e5e

Browse files
mhjacksMartin Jacksongaurav-nelson
authored
Layered Zero Trust pattern (#575)
* Initial placeholder for Layered Zero Trust * WIP:Do not merge * Added basic docs for Layered Zero Trust --------- Co-authored-by: Martin Jackson <[email protected]> Co-authored-by: Gaurav Nelson <[email protected]>
1 parent 7ecde15 commit 6182e5e

File tree

2 files changed

+277
-0
lines changed

2 files changed

+277
-0
lines changed

‎content/patterns/layered-zero-trust/_index.adoc‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
---
2+
title: Layered Zero Trust
3+
date: 2025-06-11
4+
tier: sandbox
5+
summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio.
6+
rh_products:
7+
- Red Hat OpenShift Container Platform
8+
industries:
9+
aliases: /layered-zero-trust/
10+
links:
11+
github: https://github.com/validatedpatterns/layered-zero-trust/
12+
install: https://github.com/validatedpatterns/layered-zero-trust/?tab=readme-ov-file#getting-started
13+
bugs: https://github.com/validatedpatterns/layered-zero-trust/issues
14+
feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform
15+
ci: layeredzerotrust
16+
---
17+
18+
19+
:toc:
20+
:imagesdir: /images
21+
:_mod-docs-content-type: ASSEMBLY
22+
include::modules/comm-attributes.adoc[]
23+
24+
[id="about-lzt-pattern"]
25+
= About the Layered Zero Trust pattern
26+
27+
link:https://www.redhat.com/en/topics/security/what-is-zero-trust[Zero trust] is an approach to designing security architectures based on the premise that every interaction begins in an untrusted state.
28+
The Layered Zero Trust pattern describes how to implement a zero trust architecture in a {rh-ocp} environment.
29+
The pattern identifies specific transactions between an actor and a resource within the environment.
30+
For these transactions, you can identify the context and implement policy enforcement.
31+
32+
Because of the breadth and diversity of possible interactions between components in {ocp}, this pattern is presented as a set of abstract, stackable layers.
33+
These layers provide the prerequisite capabilities that are needed to implement appropriate enforcement points.
34+
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.
35+
36+
Use case::
37+
The pattern addresses the shortcomings of traditional cybersecurity methods, such as defensive hardening and reactive detection.
38+
It is particularly effective for the following types of systems and environments:
39+
40+
* Distributed systems, such as cloud and edge environments.
41+
* Autonomous and artificial intelligence (AI) or machine learning (ML) based systems, including robotic process automation.
42+
* Large, composite systems that integrate third-party or legacy components.
43+
44+
This pattern provides specific implementations for each of these business use cases within its abstract, layered structure.
45+
46+
Background::
47+
48+
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.
49+
Attackers continuously develop new methods to evade signature-based detection and exploit systems by targeting those already deemed trustworthy.
50+
51+
In contrast, the Zero Trust architecture operates from the assumption that a breach will occur.
52+
It focuses on preventing further compromise by establishing well-defined security boundaries and enforcing a deny-all default access control stance.
53+
The pattern emphasizes significant automation and grants access dynamically, based on policies, with a least-privilege, as-needed approach.
54+
Instead of relying on signatures, it explicitly enumerates allowed actors and monitors their behavior, which is a more effective way to contain malicious activity.
55+
Zero Trust architectures incorporate contextual information and user behavior analytics to inform access decisions, proactively preventing lateral movement in case of a compromise.
56+
57+
[id="about-solution"]
58+
== About the solution
59+
60+
The Layered Zero Trust pattern implements a layered zero trust architecture that shows workload identity management, secure communication, and secret management capabilities.
61+
62+
The solution integrates many Red{nbsp}Hat components to offer:
63+
64+
* Workload identity using Secure Production Identity Framework for Everyone (SPIFFE) and SPIFFE Runtime Environment (SPIRE) standards.
65+
* Secure secret management through HashiCorp Vault.
66+
* Identity and access management by using the Red{nbsp}Hat build of Keycloak (RHBK).
67+
* Certificate management for secure communications.
68+
* External secret management integration.
69+
70+
[id="architecture"]
71+
=== Architecture
72+
73+
The Layered Zero Trust pattern architecture consists of many components that work together to offer a secure environment for applications and workloads.
74+
75+
The pattern consists of the following key components:
76+
77+
. Zero Trust Workload Identity Manager: Implements workload identity using SPIFFE/SPIRE.
78+
. HashiCorp Vault: Provides secure secret storage and management.
79+
. Red{nbsp}Hat build of Keycloak (RHBK): Manages identity and access for users and services.
80+
. OpenShift Cert Manager: Manages the lifecycle of certificates for secure communication.
81+
. External Secrets Operator: Synchronizes secrets from external systems into the cluster.
82+
. QTodo application: Serves as a Quarkus-based application to show zero trust principles.
83+
. PostgreSQL database: Provides the backend database for the demonstration application.
84+
85+
[id="sidecar-pattern"]
86+
==== Sidecar pattern
87+
88+
The sidecar pattern is a deployment model where a separate container or process, called a sidecar, runs alongside a main application to handle auxiliary tasks.
89+
In an {ocp} environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle.
90+
This approach is highly beneficial for Zero Trust architectures because it allows for the centralized enforcement of security policies, such as authentication, authorization, traffic encryption (mTLS), rate limiting, auditing, and logging, without requiring developers to build this logic into every microservice.
91+
It separates concerns, simplifies development, and allows security policies to be updated independently of the main application.
92+
93+
While sidecars are often criticized for adding complexity and resource usage, the text argues these are often misconceptions:
94+
95+
* *Complexity*: Sidecars simplify the main application by offloading tasks, and modern platforms, such as {ocp}, are designed to manage them efficiently.
96+
* *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.
97+
* *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.
98+
99+
The Layered Zero Trust pattern makes extensive use of the sidecar approach to achieve its goals by offloading critical security functions from the main application.
100+
This provides significant benefits by centralizing policy enforcement, simplifying development, and separating security concerns.
101+
The specific sidecar patterns used in this approach handle tasks, such as, authentication and authorization, traffic encryption, rate limiting, and auditing and logging.
102+
103+
[id="about-technology"]
104+
== About the technology
105+
106+
The following technologies are used in this solution:
107+
108+
* *Zero Trust Workload Identity Manager*: Implements workload identity using SPIFFE/SPIRE.
109+
* *HashiCorp Vault*: Provides secure secret storage and management.
110+
* *Red{nbsp}Hat build of Keycloak (RHBK)*: Manages identity and access for users and services.
111+
* *{rh-gitops}*: A GitOps continuous delivery (CD) solution based on ArgoCD
112+
* *OpenShift Cert Manager*: Manages the lifecycle of certificates for secure communication.
113+
* *External Secrets Operator*: Synchronizes secrets from external systems into the cluster.
114+
* *Compliance Operator*: Provides ability to scan and remediate cluster hardening based on profiles
115+
* *QTodo application*: Serves as a sample Quarkus-based application to show zero trust principles.
116+
* *PostgreSQL database*: Provides the backend database for the demonstration application.

‎content/patterns/layered-zero-trust/lzt-getting-started.adoc‎

Lines changed: 161 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,161 @@
1+
---
2+
title: Getting started
3+
weight: 10
4+
aliases: /layered-zero-trust/lzt-getting-started/
5+
---
6+
7+
:toc:
8+
:imagesdir: /images
9+
:_mod-docs-content-type: ASSEMBLY
10+
include::modules/comm-attributes.adoc[]
11+
12+
[id="lzt-deploying-lzt-pattern"]
13+
= Deploying the Layered Zero Trust pattern
14+
15+
Follow these instructions to configure and deploy the Layered Zero Trust pattern.
16+
17+
.Prerequisites
18+
19+
* An {ocp} cluster with publicly signed certificates for Ingress
20+
* A GitHub account and a token for it with repositories permissions, to read from and write to your forks.
21+
* Access to Podman (or Docker) for execution of the container images used by `pattern.sh` script for provisioning.
22+
* Useful additions:
23+
24+
** The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm]
25+
** Additional installation tool dependencies. For details, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start].
26+
27+
[id="lzt-repository-setup"]
28+
== Repository setup
29+
30+
Follow these instructions for setting up the project repository:
31+
32+
. Fork the layered-zero-trust repository from GitHub. You must fork the repository because your fork is updated as part of the GitOps and DevOps processes.
33+
. Clone your forked repository.
34+
+
35+
[source,terminal]
36+
----
37+
$ git clone [email protected]:<your_username>/layered-zero-trust.git
38+
----
39+
40+
. Go to your repository: Ensure you are in the root directory of your
41+
Git repository by using the following command:
42+
+
43+
[source,terminal]
44+
----
45+
$ cd </path_to_your_repository>
46+
----
47+
48+
. Set up upstream remote repository:
49+
+
50+
[source,terminal]
51+
----
52+
$ git remote add -f upstream [email protected]/validatedpatterns/layered-zero-trust.git
53+
----
54+
55+
. Verify the setup of your remote repositories by running the following
56+
command:
57+
+
58+
[source,terminal]
59+
----
60+
$ git remote -v
61+
----
62+
+
63+
Example output:
64+
+
65+
[source,terminal]
66+
----
67+
origin [email protected]:<your_username>/layered-zero-trust.git (fetch)
68+
origin [email protected]:<your_username>/layered-zero-trust.git (push)
69+
upstream https://github.com/validatedpatterns/layered-zero-trust.git (fetch)
70+
upstream https://github.com/validatedpatterns/layered-zero-trust.git (push)
71+
----
72+
73+
. Create a local copy of the secret values file that can safely include
74+
credentials. Run the following command:
75+
+
76+
[source,terminal]
77+
----
78+
$ cp values-secret.yaml.template ~/values-secret-layered-zero-trust.yaml
79+
----
80+
+
81+
[NOTE]
82+
====
83+
To prevent pushing secrets to your Git repository, the command places the `values-secret.yaml` file in your home directory.
84+
You derive this file from the `values-secrets.yaml.template` file located in the pattern's top-level directory.
85+
When you create new patterns, add your secrets to the `values-secret.yaml` file in your home directory.
86+
====
87+
88+
. Create a new feature branch, for example `my-branch` from the `main`
89+
branch for your content:
90+
+
91+
[source,terminal]
92+
----
93+
$ git checkout -b my-branch main
94+
----
95+
96+
. (Optional) To customize the execution of the pattern, optionally change
97+
the Helm values files and then commit the changes.
98+
+
99+
[source,terminal]
100+
----
101+
$ git add <files_you_changed>
102+
$ git commit -m "Pattern customization"
103+
----
104+
+
105+
[NOTE]
106+
====
107+
The following configuration files define the behavior and settings of the various components in the Layered Zero Trust pattern.
108+
You can customize these files to fit your specific deployment needs.
109+
110+
* `values-global.yaml`: Global pattern configuration
111+
* `values-hub.yaml`: Hub cluster specific configuration
112+
* `values-secret.yaml`: Secret values (created from template)
113+
* `values-<environment>.yaml`: Environment-specific overrides (AWS, Azure, GCP)
114+
====
115+
116+
. Push the changes from your local branch to your forked repository.
117+
+
118+
[source,terminal]
119+
----
120+
$ git push origin my-branch
121+
----
122+
123+
[id="deploying-cluster-using-patternsh-file"]
124+
== Deploying the pattern by using the pattern.sh file
125+
126+
Deploy the Layered Zero Trust pattern by using the `pattern.sh` script.
127+
128+
. Login to your {ocp} cluster:
129+
130+
.. By using the `oc` CLI:
131+
* Get an API token by visiting `pass:[https://oauth-openshift.apps.<your_cluster>.<domain>/oauth/token/request]`.
132+
* Log in with the retrieved token:
133+
+
134+
[source,terminal]
135+
----
136+
$ oc login --token=<retrieved_token> --server=https://api.<your_cluster>.<domain>:6443
137+
----
138+
139+
.. By using KUBECONFIG:
140+
+
141+
[source,terminal]
142+
----
143+
$ export KUBECONFIG=~/<path_to_kubeconfig>
144+
----
145+
146+
. Run the pattern deployment script:
147+
+
148+
[source,terminal]
149+
----
150+
$ ./pattern.sh make install
151+
----
152+
153+
[id="lzt-verify-deployment"]
154+
=== Verify the deployment
155+
156+
You can use the {ocp} console and ArgoCD applications to verify the deployment.
157+
158+
. In the {ocp} web console, navigate to the *Operators* → *Installed Operators* page.
159+
. Check that {rh-gitops} Operator is installed in the
160+
`openshift-operators` namespace and its status is Succeeded.
161+
. Use the Application Launcher within the {ocp} console to confirm that all applications have synchronized successfully to both Hub and Cluster Argo CD instances.

0 commit comments

Comments
 (0)