You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
27
-
The Layered Zero Trust pattern describes how to implement a zero trust architecture in a Red Hat OpenShift Container Platform environment.
28
+
The Layered Zero Trust pattern describes how to implement a zero trust architecture in a {rh-ocp} environment.
28
29
The pattern identifies specific transactions between an actor and a resource within the environment.
29
30
For these transactions, you can identify the context and implement policy enforcement.
30
31
31
-
Because of the breadth and diversity of possible interactions between components in OpenShift Container Platform, this pattern is presented as a set of abstract, stackable layers.
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.
32
33
These layers provide the prerequisite capabilities that are needed to implement appropriate enforcement points.
33
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.
34
35
@@ -51,48 +52,48 @@ In contrast, the Zero Trust architecture operates from the assumption that a bre
51
52
It focuses on preventing further compromise by establishing well-defined security boundaries and enforcing a deny-all default access control stance.
52
53
The pattern emphasizes significant automation and grants access dynamically, based on policies, with a least-privilege, as-needed approach.
53
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.
54
-
Zero Trust architectures incorporate contextual information and user behavior analytics to inform access decisions, proactively preventing lateral movement in the event of a compromise.
55
+
Zero Trust architectures incorporate contextual information and user behavior analytics to inform access decisions, proactively preventing lateral movement in case of a compromise.
55
56
56
57
[id="about-solution"]
57
58
== About the solution
58
59
59
-
The Layered Zero Trust pattern implements a layered zero trust architecture that demonstrates workload identity management, secure communication, and secret management capabilities.
60
+
The Layered Zero Trust pattern implements a layered zero trust architecture that shows workload identity management, secure communication, and secret management capabilities.
60
61
61
-
The solution integrates multiple RedHat components to provide:
62
+
The solution integrates many Red{nbsp}Hat components to offer:
62
63
63
64
* Workload identity using Secure Production Identity Framework for Everyone (SPIFFE) and SPIFFE Runtime Environment (SPIRE) standards.
64
65
* Secure secret management through HashiCorp Vault.
65
-
* Identity and access management by using the RedHat build of Keycloak (RHBK).
66
+
* Identity and access management by using the Red{nbsp}Hat build of Keycloak (RHBK).
66
67
* Certificate management for secure communications.
67
68
* External secret management integration.
68
69
69
70
[id="architecture"]
70
71
=== Architecture
71
72
72
-
The Layered Zero Trust pattern architecture consists of multiple components that work together to provide a secure environment for applications and workloads.
73
+
The Layered Zero Trust pattern architecture consists of many components that work together to offer a secure environment for applications and workloads.
73
74
74
75
The pattern consists of the following key components:
75
76
76
77
. Zero Trust Workload Identity Manager: Implements workload identity using SPIFFE/SPIRE.
77
78
. HashiCorp Vault: Provides secure secret storage and management.
78
-
. RedHat build of Keycloak (RHBK): Manages identity and access for users and services.
79
+
. Red{nbsp}Hat build of Keycloak (RHBK): Manages identity and access for users and services.
79
80
. OpenShift Cert Manager: Manages the lifecycle of certificates for secure communication.
80
81
. External Secrets Operator: Synchronizes secrets from external systems into the cluster.
81
-
. QTodo application: Serves as a Quarkus-based application to demonstrate zero trust principles.
82
+
. QTodo application: Serves as a Quarkus-based application to show zero trust principles.
82
83
. PostgreSQL database: Provides the backend database for the demonstration application.
83
84
84
85
[id="sidecar-pattern"]
85
86
==== Sidecar pattern
86
87
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.
88
-
In an OpenShift environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle.
89
+
In an {ocp} environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle.
89
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.
90
91
It separates concerns, simplifies development, and allows security policies to be updated independently of the main application.
91
92
92
93
While sidecars are often criticized for adding complexity and resource usage, the text argues these are often misconceptions:
93
94
94
-
* *Complexity*: Sidecars simplify the main application by offloading tasks, and modern platforms like OpenShift are designed to manage them efficiently.
95
-
* *Resource Usage*: The resource cost of a sidecar is often minimal compared to the overhead of integrating security logic into every application.
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.
96
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.
97
98
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.
@@ -106,10 +107,10 @@ The following technologies are used in this solution:
Follow the instructions in this section to configure and deploy the Layered Zero Trust pattern.
15
+
Follow these instructions to configure and deploy the Layered Zero Trust pattern.
16
16
17
17
.Prerequisites
18
18
19
-
* An OpenShift cluster with publicly signed certificates for Ingress
19
+
* An {ocp} cluster with publicly signed certificates for Ingress
20
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.
21
+
* Access to Podman (or Docker) for execution of the container images used by `pattern.sh` script for provisioning.
22
22
* Useful additions:
23
23
24
24
** The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm]
@@ -29,22 +29,20 @@ Follow the instructions in this section to configure and deploy the Layered Zero
29
29
30
30
Follow these instructions for setting up the project repository:
31
31
32
-
. Fork the layered-zero-trust repository from GitHub. You must fork the
33
-
repository because your fork is updated as part of the GitOps and DevOps
34
-
processes.
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.
You can use the OpenShift console and ArgoCD applications to verify the
163
-
deployment.
156
+
You can use the {ocp} console and ArgoCD applications to verify the deployment.
164
157
165
-
. In the OpenShift web console, navigate to Operators → Installed
166
-
Operators page.
167
-
. Check that Red Hat OpenShift GitOps Operator is installed in the
168
-
openshift-operators namespace and its status is Succeeded.
169
-
. Use the Application Launcher within the OpenShift console to confirm
170
-
that all applications have synchronized successfully to both Hub and
171
-
Cluster Argo CD instances.
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