From 72993016a10a37b0756315b171bcd64c2ac13517 Mon Sep 17 00:00:00 2001 From: Martin Jackson Date: Wed, 11 Jun 2025 10:39:49 -0500 Subject: [PATCH 1/3] Initial placeholder for Layered Zero Trust --- content/patterns/layered-zero-trust/_index.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/patterns/layered-zero-trust/_index.md diff --git a/content/patterns/layered-zero-trust/_index.md b/content/patterns/layered-zero-trust/_index.md new file mode 100644 index 000000000..85e07c8c3 --- /dev/null +++ b/content/patterns/layered-zero-trust/_index.md @@ -0,0 +1,20 @@ +--- +title: Layered Zero Trust +date: 2025-06-11 +tier: sandbox +summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio +rh_products: +- Red Hat OpenShift Container Platform +industries: +aliases: /layered-zero-trust/ +links: + github: https://github.com/validatedpatterns/layered-zero-trust/ + install: https://github.com/validatedpatterns/layered-zero-trust/?tab=readme-ov-file#getting-started + bugs: https://github.com/validatedpatterns/layered-zero-trust/issues + feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform +--- + +# Layered Zero Trust + +The Layered Zero Trust will demonstrate how to use several technologies in and adjacent to the Red Hat Portfolio +to implement Zero Trust principles for development and operations. From 61822a96973d02ee6bcbde62d27fc39ac7c4a94f Mon Sep 17 00:00:00 2001 From: Gaurav Nelson <23069445+gaurav-nelson@users.noreply.github.com> Date: Fri, 12 Sep 2025 11:20:49 +1000 Subject: [PATCH 2/3] WIP:Do not merge --- .../patterns/layered-zero-trust/_index.adoc | 115 ++++++++++++ content/patterns/layered-zero-trust/_index.md | 20 -- .../lzt-getting-started.adoc | 171 ++++++++++++++++++ 3 files changed, 286 insertions(+), 20 deletions(-) create mode 100644 content/patterns/layered-zero-trust/_index.adoc delete mode 100644 content/patterns/layered-zero-trust/_index.md create mode 100644 content/patterns/layered-zero-trust/lzt-getting-started.adoc diff --git a/content/patterns/layered-zero-trust/_index.adoc b/content/patterns/layered-zero-trust/_index.adoc new file mode 100644 index 000000000..4946a1e25 --- /dev/null +++ b/content/patterns/layered-zero-trust/_index.adoc @@ -0,0 +1,115 @@ +--- +title: Layered Zero Trust +date: 2025-06-11 +tier: sandbox +summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio +rh_products: +- Red Hat OpenShift Container Platform +industries: +aliases: /layered-zero-trust/ +links: + github: https://github.com/validatedpatterns/layered-zero-trust/ + install: https://github.com/validatedpatterns/layered-zero-trust/?tab=readme-ov-file#getting-started + bugs: https://github.com/validatedpatterns/layered-zero-trust/issues + feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform +--- + + +:toc: +:imagesdir: /images +:_content-type: ASSEMBLY +include::modules/comm-attributes.adoc[] + +[id="about-lzt-pattern"] += About the Layered Zero Trust pattern + +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. +The Layered Zero Trust pattern describes how to implement a zero trust architecture in a Red Hat OpenShift Container Platform environment. +The pattern identifies specific transactions between an actor and a resource within the environment. +For these transactions, you can identify the context and implement policy enforcement. + +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. +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 the event of a compromise. + +[id="about-solution"] +== About the solution + +The Layered Zero Trust pattern implements a layered zero trust architecture that demonstrates workload identity management, secure communication, and secret management capabilities. + +The solution integrates multiple Red Hat components to provide: + +* 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. + +[id="architecture"] +=== Architecture + +The Layered Zero Trust pattern architecture consists of multiple components that work together to provide 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 demonstrate zero trust principles. +. PostgreSQL database: Provides the backend database for the demonstration application. + +[id="sidecar-pattern"] +==== Sidecar pattern + +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. +In an OpenShift environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle. +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. +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, the text argues these are often misconceptions: + +* *Complexity*: Sidecars simplify the main application by offloading tasks, and modern platforms like OpenShift are designed to manage them efficiently. +* *Resource Usage*: The resource cost of a sidecar is often minimal compared to the overhead of integrating 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 makes extensive use of the sidecar approach to achieve its goals by offloading critical security functions from the main application. +This provides significant benefits by centralizing policy enforcement, simplifying development, and separating security concerns. +The specific sidecar patterns used in this approach handle tasks, such as, authentication and authorization, traffic encryption, rate limiting, and auditing and logging. + +[id="about-technology"] +== 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 demonstrate zero trust principles. +* *PostgreSQL database*: Provides the backend database for the demonstration application. diff --git a/content/patterns/layered-zero-trust/_index.md b/content/patterns/layered-zero-trust/_index.md deleted file mode 100644 index 85e07c8c3..000000000 --- a/content/patterns/layered-zero-trust/_index.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Layered Zero Trust -date: 2025-06-11 -tier: sandbox -summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio -rh_products: -- Red Hat OpenShift Container Platform -industries: -aliases: /layered-zero-trust/ -links: - github: https://github.com/validatedpatterns/layered-zero-trust/ - install: https://github.com/validatedpatterns/layered-zero-trust/?tab=readme-ov-file#getting-started - bugs: https://github.com/validatedpatterns/layered-zero-trust/issues - feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform ---- - -# Layered Zero Trust - -The Layered Zero Trust will demonstrate how to use several technologies in and adjacent to the Red Hat Portfolio -to implement Zero Trust principles for development and operations. diff --git a/content/patterns/layered-zero-trust/lzt-getting-started.adoc b/content/patterns/layered-zero-trust/lzt-getting-started.adoc new file mode 100644 index 000000000..3e7350035 --- /dev/null +++ b/content/patterns/layered-zero-trust/lzt-getting-started.adoc @@ -0,0 +1,171 @@ +--- +title: Getting started +weight: 10 +aliases: /layered-zero-trust/lzt-getting-started/ +--- + +:toc: +:imagesdir: /images +:_content-type: ASSEMBLY +include::modules/comm-attributes.adoc[] + +[id="lzt-deploying-lzt-pattern"] += Deploying the Layered Zero Trust pattern + +Follow the instructions in this section to configure and deploy the Layered Zero Trust pattern. + +.Prerequisites + +* An OpenShift cluster with publicly signed certificates for Ingress +* A GitHub account and a token for it with repositories permissions, to read from and write to your forks. +* Access to podman (or docker) for execution of the container images used by `pattern.sh` script for provisioning. +* Useful additions: + +** The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm] +** Additional installation tool dependencies. For details, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start]. + +[id="lzt-repository-setup"] +== Repository setup + +Follow these instructions for setting up the project repository: + +. 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. +. Clone your forked repository. ++ +[source,terminal] +---- +$ git clone git@github.com:/layered-zero-trust.git +---- + +. Go to your repository: Ensure you are in the root directory of your +Git repository by using the following command: ++ +[source,terminal] +---- +$ cd +---- + +. Set up upstream remote repository: ++ +[source,terminal] +---- +$ git remote add -f upstream git@github.com/validatedpatterns/layered-zero-trust.git +---- + +. Verify the setup of your remote repositories by running the following +command: ++ +[source,terminal] +---- +$ git remote -v +---- ++ +Example output: ++ +[source,terminal] +---- +origin git@github.com:/layered-zero-trust.git (fetch) +origin git@github.com:/layered-zero-trust.git (push) +upstream https://github.com/validatedpatterns/layered-zero-trust.git (fetch) +upstream https://github.com/validatedpatterns/layered-zero-trust.git (push) +---- + +. Create a local copy of the secret values file that can safely include +credentials. Run the following command: ++ +[source,terminal] +---- +$ cp values-secret.yaml.template ~/values-secret-layered-zero-trust.yaml +---- ++ +[NOTE] +==== +To prevent your secrets from being pushed to your Git repository, +the command places the `values-secret.yaml` file in your home directory. +This file is derived from the `values-secrets.yaml.template` file, which +is located in the pattern’s top-level directory. When creating new +patterns, you should add your secrets to the `values-secret.yaml` file +in your home directory. +==== + +. Create a new feature branch, for example `my-branch` from the `main` +branch for your content: ++ +[source,terminal] +---- +$ git checkout -b my-branch main +---- + +. (Optional) To customize the execution of the pattern, optionally change +the Helm values files and then commit the changes. ++ +[source,terminal] +---- +$ git add +$ git commit -m "Pattern customization" +---- ++ +[NOTE] +==== +The following configuration files define the behavior and settings +of the various components in the Layered Zero Trust pattern. You can +customize these files to fit your specific deployment needs. + +* `values-global.yaml`: Global pattern configuration +* `values-hub.yaml`: Hub cluster specific configuration +* `values-secret.yaml`: Secret values (created from template) +* `values-.yaml`: Environment-specific overrides (AWS, Azure, GCP) +==== + +. Push the changes from your local branch to your forked repository. ++ +[source,terminal] +---- +$ git push origin my-branch +---- + +[id="deploying-cluster-using-patternsh-file"] +== Deploying the pattern by using the pattern.sh file + +Deploy the Layered Zero Trust pattern using the `pattern.sh` script. + +. Login to your OpenShift cluster: + +.. By using the `oc` CLI: +* Get an API token by visiting `pass:[https://oauth-openshift.apps../oauth/token/request]`. +* Log in with the retrieved token: ++ +[source,terminal] +---- +$ oc login --token= --server=https://api..:6443 +---- + +.. By using KUBECONFIG: ++ +[source,terminal] +---- +$ export KUBECONFIG=~/ +---- + +. Run the pattern deployment script: ++ +[source,terminal] +---- +$ ./pattern.sh make install +---- + +[id="lzt-verify-deployment"] +=== Verify the deployment + +You can use the OpenShift console and ArgoCD applications to verify the +deployment. + +. In the OpenShift web console, navigate to Operators → Installed +Operators page. +. Check that Red Hat OpenShift GitOps Operator is installed in the +openshift-operators namespace and its status is Succeeded. +. Use the Application Launcher within the OpenShift console to confirm +that all applications have synchronized successfully to both Hub and +Cluster Argo CD instances. From f3626023c8969cf84eb748ca4b21392429f3fe44 Mon Sep 17 00:00:00 2001 From: Gaurav Nelson <23069445+gaurav-nelson@users.noreply.github.com> Date: Fri, 12 Sep 2025 17:39:15 +1000 Subject: [PATCH 3/3] Added basic docs for Layered Zero Trust --- .../patterns/layered-zero-trust/_index.adoc | 35 +++++------ .../lzt-getting-started.adoc | 58 ++++++++----------- 2 files changed, 42 insertions(+), 51 deletions(-) diff --git a/content/patterns/layered-zero-trust/_index.adoc b/content/patterns/layered-zero-trust/_index.adoc index 4946a1e25..80853cd57 100644 --- a/content/patterns/layered-zero-trust/_index.adoc +++ b/content/patterns/layered-zero-trust/_index.adoc @@ -2,7 +2,7 @@ title: Layered Zero Trust date: 2025-06-11 tier: sandbox -summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio +summary: Layered Zero Trust demonstrates how to operationalize Zero Trust security principles when using products in the Red Hat Portfolio. rh_products: - Red Hat OpenShift Container Platform industries: @@ -12,23 +12,24 @@ links: install: https://github.com/validatedpatterns/layered-zero-trust/?tab=readme-ov-file#getting-started bugs: https://github.com/validatedpatterns/layered-zero-trust/issues feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform +ci: layeredzerotrust --- :toc: :imagesdir: /images -:_content-type: ASSEMBLY +:_mod-docs-content-type: ASSEMBLY include::modules/comm-attributes.adoc[] [id="about-lzt-pattern"] = About the Layered Zero Trust pattern 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. -The Layered Zero Trust pattern describes how to implement a zero trust architecture in a Red Hat OpenShift Container Platform environment. +The Layered Zero Trust pattern describes how to implement a zero trust architecture in a {rh-ocp} environment. The pattern identifies specific transactions between an actor and a resource within the environment. For these transactions, you can identify the context and implement policy enforcement. -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. +Because of the breadth and diversity of possible interactions between components in {ocp}, 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. @@ -51,48 +52,48 @@ In contrast, the Zero Trust architecture operates from the assumption that a bre 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 the event of a compromise. +Zero Trust architectures incorporate contextual information and user behavior analytics to inform access decisions, proactively preventing lateral movement in case of a compromise. [id="about-solution"] == About the solution -The Layered Zero Trust pattern implements a layered zero trust architecture that demonstrates workload identity management, secure communication, and secret management capabilities. +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 multiple Red Hat components to provide: +The solution integrates many Red{nbsp}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). +* Identity and access management by using the Red{nbsp}Hat build of Keycloak (RHBK). * Certificate management for secure communications. * External secret management integration. [id="architecture"] === Architecture -The Layered Zero Trust pattern architecture consists of multiple components that work together to provide a secure environment for applications and workloads. +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. +. Red{nbsp}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 demonstrate zero trust principles. +. QTodo application: Serves as a Quarkus-based application to show zero trust principles. . PostgreSQL database: Provides the backend database for the demonstration application. [id="sidecar-pattern"] ==== Sidecar pattern 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. -In an OpenShift environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle. +In an {ocp} environment, this is simplified through the use of pods, which ensure the sidecar and main application share the same lifecycle. 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. 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, the text argues these are often misconceptions: -* *Complexity*: Sidecars simplify the main application by offloading tasks, and modern platforms like OpenShift are designed to manage them efficiently. -* *Resource Usage*: The resource cost of a sidecar is often minimal compared to the overhead of integrating security logic into every application. +* *Complexity*: Sidecars simplify the main application by offloading tasks, and modern platforms, such as {ocp}, 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 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: * *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 +* *Red{nbsp}Hat build of Keycloak (RHBK)*: Manages identity and access for users and services. +* *{rh-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 demonstrate zero trust principles. +* *QTodo application*: Serves as a sample Quarkus-based application to show zero trust principles. * *PostgreSQL database*: Provides the backend database for the demonstration application. diff --git a/content/patterns/layered-zero-trust/lzt-getting-started.adoc b/content/patterns/layered-zero-trust/lzt-getting-started.adoc index 3e7350035..dd74a538e 100644 --- a/content/patterns/layered-zero-trust/lzt-getting-started.adoc +++ b/content/patterns/layered-zero-trust/lzt-getting-started.adoc @@ -6,19 +6,19 @@ aliases: /layered-zero-trust/lzt-getting-started/ :toc: :imagesdir: /images -:_content-type: ASSEMBLY +:_mod-docs-content-type: ASSEMBLY include::modules/comm-attributes.adoc[] [id="lzt-deploying-lzt-pattern"] = Deploying the Layered Zero Trust pattern -Follow the instructions in this section to configure and deploy the Layered Zero Trust pattern. +Follow these instructions to configure and deploy the Layered Zero Trust pattern. .Prerequisites -* An OpenShift cluster with publicly signed certificates for Ingress +* An {ocp} cluster with publicly signed certificates for Ingress * A GitHub account and a token for it with repositories permissions, to read from and write to your forks. -* Access to podman (or docker) for execution of the container images used by `pattern.sh` script for provisioning. +* Access to Podman (or Docker) for execution of the container images used by `pattern.sh` script for provisioning. * Useful additions: ** The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm] @@ -29,14 +29,12 @@ Follow the instructions in this section to configure and deploy the Layered Zero Follow these instructions for setting up the project repository: -. 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. +. 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. . Clone your forked repository. + [source,terminal] ---- -$ git clone git@github.com:/layered-zero-trust.git +$ git clone git@github.com:/layered-zero-trust.git ---- . Go to your repository: Ensure you are in the root directory of your @@ -44,7 +42,7 @@ Git repository by using the following command: + [source,terminal] ---- -$ cd +$ cd ---- . Set up upstream remote repository: @@ -66,8 +64,8 @@ Example output: + [source,terminal] ---- -origin git@github.com:/layered-zero-trust.git (fetch) -origin git@github.com:/layered-zero-trust.git (push) +origin git@github.com:/layered-zero-trust.git (fetch) +origin git@github.com:/layered-zero-trust.git (push) upstream https://github.com/validatedpatterns/layered-zero-trust.git (fetch) upstream https://github.com/validatedpatterns/layered-zero-trust.git (push) ---- @@ -82,12 +80,9 @@ $ cp values-secret.yaml.template ~/values-secret-layered-zero-trust.yaml + [NOTE] ==== -To prevent your secrets from being pushed to your Git repository, -the command places the `values-secret.yaml` file in your home directory. -This file is derived from the `values-secrets.yaml.template` file, which -is located in the pattern’s top-level directory. When creating new -patterns, you should add your secrets to the `values-secret.yaml` file -in your home directory. +To prevent pushing secrets to your Git repository, the command places the `values-secret.yaml` file in your home directory. +You derive this file from the `values-secrets.yaml.template` file located in the pattern's top-level directory. +When you create new patterns, add your secrets to the `values-secret.yaml` file in your home directory. ==== . Create a new feature branch, for example `my-branch` from the `main` @@ -103,15 +98,14 @@ the Helm values files and then commit the changes. + [source,terminal] ---- -$ git add +$ git add $ git commit -m "Pattern customization" ---- + [NOTE] ==== -The following configuration files define the behavior and settings -of the various components in the Layered Zero Trust pattern. You can -customize these files to fit your specific deployment needs. +The following configuration files define the behavior and settings of the various components in the Layered Zero Trust pattern. +You can customize these files to fit your specific deployment needs. * `values-global.yaml`: Global pattern configuration * `values-hub.yaml`: Hub cluster specific configuration @@ -129,17 +123,17 @@ $ git push origin my-branch [id="deploying-cluster-using-patternsh-file"] == Deploying the pattern by using the pattern.sh file -Deploy the Layered Zero Trust pattern using the `pattern.sh` script. +Deploy the Layered Zero Trust pattern by using the `pattern.sh` script. -. Login to your OpenShift cluster: +. Login to your {ocp} cluster: .. By using the `oc` CLI: -* Get an API token by visiting `pass:[https://oauth-openshift.apps../oauth/token/request]`. +* Get an API token by visiting `pass:[https://oauth-openshift.apps../oauth/token/request]`. * Log in with the retrieved token: + [source,terminal] ---- -$ oc login --token= --server=https://api..:6443 +$ oc login --token= --server=https://api..:6443 ---- .. By using KUBECONFIG: @@ -159,13 +153,9 @@ $ ./pattern.sh make install [id="lzt-verify-deployment"] === Verify the deployment -You can use the OpenShift console and ArgoCD applications to verify the -deployment. +You can use the {ocp} console and ArgoCD applications to verify the deployment. -. In the OpenShift web console, navigate to Operators → Installed -Operators page. -. Check that Red Hat OpenShift GitOps Operator is installed in the -openshift-operators namespace and its status is Succeeded. -. Use the Application Launcher within the OpenShift console to confirm -that all applications have synchronized successfully to both Hub and -Cluster Argo CD instances. +. In the {ocp} web console, navigate to the *Operators* → *Installed Operators* page. +. Check that {rh-gitops} Operator is installed in the +`openshift-operators` namespace and its status is Succeeded. +. Use the Application Launcher within the {ocp} console to confirm that all applications have synchronized successfully to both Hub and Cluster Argo CD instances.