validatedpatterns · sabre1041 · Apr 7, 2026 · Apr 1, 2026 · Apr 1, 2026 · Apr 7, 2026
diff --git a/README.md b/README.md
@@ -11,33 +11,66 @@
 
 Showcases the Zero Trust capabilities across Red Hat's product portfolio in a reproducible manner.
 
+### Architecture Overview
+
+The pattern is structured in layers, each building on the one below it:
+
+* **Validated Patterns Framework** — bootstraps the cluster using OpenShift GitOps (ArgoCD) and the Validated Patterns Operator. All subsequent components are deployed and reconciled by ArgoCD.
+* **Layer 0 — Cluster Hardening** — establishes a secure cluster baseline: TLS certificate management, compliance scanning, advanced cluster management, and runtime security enforcement.
+* **Layer 1 — Identity & Secrets** — provisions workload identities (SPIFFE/SPIRE), manages secrets (Vault + ESO), and provides user authentication (Keycloak). Optionally includes a private image registry (Quay + NooBaa).
+* **Layer 2 — Workloads & Supply Chain** — deploys the demo application (qtodo) and, optionally, the full secure supply chain pipeline (RHTAS, RHTPA, OpenShift Pipelines).
+
+See `docs/diagrams/` for logical and schematic diagrams of the pattern.
+
 ### Components
 
-The following components are included in the Layered Zero Trust Pattern
+Components are grouped by their origin and whether they are always deployed or opt-in.
+
+#### Validated Patterns Framework (provided by the VP project)
+
+These components are part of every Validated Pattern and are not specific to ZTVP. Their Helm charts live in the [validatedpatterns](https://github.com/validatedpatterns) organization.
+
+* [OpenShift GitOps (ArgoCD)](https://docs.redhat.com/en/documentation/red_hat_openshift_gitops)
+  * Deploys and continuously reconciles all pattern components via GitOps
+* [Validated Patterns Operator](https://validatedpatterns.io)
+  * Bootstraps the pattern, manages the Hub/Spoke lifecycle, and drives imperative jobs
+
+#### Core ZTVP Components (always deployed)
+
+These components are deployed by default with every ZTVP installation. Components marked with _(externalized chart)_ use Helm charts maintained in the [validatedpatterns](https://github.com/validatedpatterns) organization rather than local charts in this repository.
 
 * OpenShift cluster hardening
-  * [Compliance Operator](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/security_and_compliance/compliance-operator)
-* [Red Hat Build of Keycloak](https://access.redhat.com/products/red-hat-build-of-keycloak/)
-  * Identities to access pattern components
-  * OIDC client to authenticate uses to a web application
-* [Red Hat Zero Trust Workload Identity Manager](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/security_and_compliance/zero-trust-workload-identity-manager)
-  * Provides identities to workloads running within OpenShift
+  * [Compliance Operator](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/security_and_compliance/compliance-operator) _(externalized chart)_
+    * Continuously scans the cluster against CIS and other security profiles
+  * [cert-manager](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/security_and_compliance/cert-manager-operator-for-red-hat-openshift)
+    * Manages TLS certificates for pattern components
+* [Red Hat Advanced Cluster Management (ACM)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14)
+  * Provides a management control plane in multi-cluster scenarios
+* [Red Hat Advanced Cluster Security (ACS)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes)
+  * Provides runtime security policy enforcement and image vulnerability scanning
 * [HashiCorp Vault](https://www.hashicorp.com/en/products/vault)
-  * Secure storage of sensitive assets
+  * Secure storage of sensitive assets and dynamic secret generation
 * [External Secrets Operator (ESO)](https://external-secrets.io)
   * Synchronizes secrets stored in HashiCorp Vault with OpenShift
-* [Red Hat Advanced Cluster Management (ACM)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14)
-  * Provides a management control in multi-cluster scenarios
-* [Red Hat Quay](https://docs.redhat.com/en/documentation/red_hat_quay/3.15)
-  * Enables a private repository for OCI images within the environment
-* [Multicloud Object Gateway](https://docs.redhat.com/en/documentation/red_hat_openshift_container_storage/4.8/html/managing_hybrid_and_multicloud_resources/index)
-  * Provides an object storage service for OpenShift
+* [Red Hat Build of Keycloak (RHBK)](https://access.redhat.com/products/red-hat-build-of-keycloak/) _(externalized chart)_
+  * Provides user identities and OIDC authentication for pattern components and workloads
+* [Red Hat Zero Trust Workload Identity Manager (ZTWIM)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/security_and_compliance/zero-trust-workload-identity-manager) _(externalized chart)_
+  * Automates provisioning of SPIFFE/SPIRE-based verifiable identities for workloads running within OpenShift
+
+#### Optional ZTVP Components (opt-in)
+
+These components are commented out in `values-hub.yaml` by default. Uncomment the relevant sections to enable them. See [Deploy the pattern](#deploy-the-pattern) for details.
+
+* [Red Hat Quay](https://docs.redhat.com/en/documentation/red_hat_quay/3.15) _(externalized chart)_
+  * Enables a private OCI image registry within the environment
+* [Multicloud Object Gateway (NooBaa MCG)](https://docs.redhat.com/en/documentation/red_hat_openshift_container_storage/4.8/html/managing_hybrid_and_multicloud_resources/index)
+  * Provides S3-compatible object storage for Quay and RHTPA
 * [Red Hat Trusted Artifact Signer (RHTAS)](https://docs.redhat.com/en/documentation/red_hat_trusted_artifact_signer/1.3)
   * Provides cryptographic signing and verification of software artifacts and container images
-* [Red Hat Trusted Profile Analyzer (RHTPA)](https://docs.redhat.com/es/documentation/red_hat_trusted_profile_analyzer/2.2)
-  * Provides the storage and management means for _Software Bill of Materials_ (SBOMs), with cross-referencing capabilities between SBOMs and CVEs/Security Advisories
+* [Red Hat Trusted Profile Analyzer (RHTPA)](https://docs.redhat.com/en/documentation/red_hat_trusted_profile_analyzer/2.2)
+  * Stores and manages _Software Bill of Materials_ (SBOMs) with cross-referencing against CVEs and Security Advisories
 * [Red Hat OpenShift Pipelines](https://docs.redhat.com/en/documentation/red_hat_openshift_pipelines/1.20)
-  * Enables a native CI/CD solution in OpenShift
+  * Enables the native CI/CD pipeline for the secure supply chain use case
 
 ## Getting Started
 
@@ -75,7 +108,7 @@ Utilize the following steps to prepare your machine and complete any and all pre
 4. Run the following command to set the upstream repository:
 
     ```shell
-    git remote add -f upstream git@github.com/validatedpatterns/layered-zero-trust.git
+    git remote add -f upstream git@github.com:validatedpatterns/layered-zero-trust.git
     ```
 
 5. Verify the setup of your remote repositories by running the following command:
@@ -171,6 +204,8 @@ If all of the Argo CD applications are reporting healthy, the pattern has been d
 
 * [Secure Multi-tier Application](./docs/multi-tier.md)
 * [Secure Supply Chain](./docs/supply-chain.md)
+* [ACS Deployment Details](./docs/acs-deployment.md)
+* [Confidential Containers (CoCo)](./docs/CONFIDENTIAL-CONTAINERS.md)
 
 ### Importing existing clusters
 

diff --git a/docs/DEVELOPMENT.md b/docs/DEVELOPMENT.md
@@ -71,6 +71,88 @@ If we want to save some space, we can add these overrides to the `noobaa-mcg` co
           value: 25Gi
 ```
 
+## Accessing Credentials for Testing
+
+All sensitive credentials in this pattern are generated automatically and stored in HashiCorp Vault during deployment. There are no static default passwords. This section explains how to retrieve credentials for testing and exploration.
+
+### Retrieve the Vault Root Token
+
+The Vault initialization data, including the root token, is stored in a Kubernetes Secret in the `imperative` namespace. Run the following command to extract the root token:
+
+```shell
+oc extract -n imperative secret/vaultkeys --to=- --keys=vault_data_json 2>/dev/null \
+  | jq -r ".root_token"
+```
+
+Save this value — you will need it to authenticate to Vault in the steps below.
+
+### Access the Vault Web UI
+
+Get the Vault route URL and open it in a browser:
+
+```shell
+echo "https://$(oc get route -n vault vault -o jsonpath='{.spec.host}')"
+```
+
+On the login screen select **Token** as the authentication method and paste the root token retrieved above.
+
+### Access Vault via CLI (`oc exec`)
+
+You can query Vault directly from inside the `vault-0` pod without installing any local tooling. First export the token into a shell variable:
+
+```shell
+VAULT_TOKEN=$(oc extract -n imperative secret/vaultkeys --to=- --keys=vault_data_json 2>/dev/null \
+  | jq -r ".root_token")
+```
+
+Then use `oc exec` to run Vault commands. For example, to list the top-level secret paths:
+
+```shell
+oc exec -n vault vault-0 -- env VAULT_TOKEN="$VAULT_TOKEN" vault kv list secret/
+```
+
+To read a specific secret, use `vault kv get`. For example, to read the Keycloak user credentials:
+
+```shell
+oc exec -n vault vault-0 -- env VAULT_TOKEN="$VAULT_TOKEN" \
+  vault kv get secret/hub/infra/users/keycloak-users
+```
+
+### Key Secret Paths
+
+Secrets are organized by component under the `secret/` KV mount. The table below lists the paths relevant to testing the default pattern deployment.
+
+| Path | Contents |
+|---|---|
+| `secret/apps/qtodo/qtodo-db` | `admin-password`, `db-password` — PostgreSQL credentials for the qtodo app |
+| `secret/apps/qtodo/qtodo-truststore` | `truststore-password` — Keycloak TLS truststore password for qtodo |
+| `secret/hub/infra/keycloak/keycloak` | `admin-password`, `db-password` — Keycloak admin and database credentials |
+| `secret/hub/infra/users/keycloak-users` | `qtodo-admin-password`, `qtodo-user1-password`, `rhtpa-user-password`, `rhtas-user-password` — application user passwords provisioned in Keycloak |
+| `secret/hub/infra/acs/acs-central` | `admin-password` — ACS Central admin password |
+| `secret/hub/infra/quay/quay-users` | `quay-admin-password`, `quay-user-password` — Quay registry credentials _(optional component)_ |
+| `secret/hub/infra/rhtpa/rhtpa-db` | `db-password` — RHTPA PostgreSQL password _(optional component)_ |
+| `secret/hub/infra/rhtpa/rhtpa-oidc-cli` | `client-secret` — RHTPA Keycloak OIDC client secret _(optional component)_ |
+
+### Shortcut: Reading ESO-Synced Secrets from Kubernetes
+
+Several secrets are automatically synchronized from Vault to Kubernetes Secrets by the External Secrets Operator (ESO). These can be read directly without going through Vault and are useful when you just need a quick credential lookup.
+
+Keycloak user passwords (synced to `keycloak-system`):
+
+```shell
+oc get secret -n keycloak-system keycloak-users -o json \
+  | jq -r '.data | map_values(@base64d)'
+```
+
+ACS Central admin password (synced to `stackrox`):
+
+```shell
+oc get secret -n stackrox central-htpasswd -o jsonpath='{.data.password}' | base64 -d
+```
+
+> [!NOTE]
+> The root token grants unrestricted access to all secrets in Vault. Use it only for development and testing. For day-to-day exploration of a specific component's credentials, prefer the narrower ESO-synced Kubernetes Secrets shown above.
+
 ## Analytics Tracking
 
 Metrics are captured to track the use of any of the Validated Patterns. It is important than an accurate depiction of pattern use by customers, partners and those from the community are captured. Red Hat associates should not factor into this calculation and support is available in the Validated Patterns framework to opt out of being captured.

diff --git a/docs/multi-tier.md b/docs/multi-tier.md
@@ -2,10 +2,10 @@
 
 One of the most common application design patterns makes use of a frontend application leveraging a database for persistent storage. Instead of traditional methods for accessing the database from the frontend application using static values stored within the application, this pattern will make use "just in time" methods for obtaining these database values from a credential store. A more detailed overview is located below:
 
-* qtodo - [Quarkus](https://quarkus.io) based frontend application. Access is protected via OIDC based authentication with users defined within an external identity store (Red Hat Build of Keycloak by default)
+* qtodo - [Quarkus](https://quarkus.io) based frontend application. Access is protected via OIDC based authentication with users defined within an external identity store ([Red Hat Build of Keycloak](https://access.redhat.com/products/red-hat-build-of-keycloak/) by default)
 * PostgreSQL - Relational database for use by the qtodo application. Credentials are generated dynamically and stored within Vault.
 * External Identity store - Users have been defined to enable access to the qtodo frontend. OIDC clients have also been created and configured within the todo application
-* HashiCorp Vault - Several features are being leveraged within this use case the external identity store
+* HashiCorp Vault - Several features are being leveraged within this use case for the external identity store
   * Secrets store - Storage of sensitive values for components including PostgreSQL and RHBK
   * JWT based authentication - Enables access using ZTWIM based identities
 * Zero Trust Workload Identity - Enables an identity to be assigned to the qtodo application to communicate with HashiCorp Vault and obtain the credentials to access the PostgreSQL database

diff --git a/docs/supply-chain.md b/docs/supply-chain.md
@@ -4,6 +4,22 @@ This use case outlines the process of building, signing, and verifying artifacts
 
 In this project, we used the [qtodo](https://github.com/validatedpatterns-demos/qtodo/) application as a sample to show how to build a secure supply chain in a software development factory.
 
+> [!IMPORTANT]
+> The Secure Supply Chain use case depends on **optional components** that are disabled by default. Before following this guide, uncomment the following sections in `values-hub.yaml` and redeploy the pattern with `./pattern.sh make install`:
+>
+> * `subscriptions.openshift-pipelines` — Red Hat OpenShift Pipelines operator
+> * `namespaces` entry for `openshift-pipelines`
+> * `applications.supply-chain` — the supply chain Tekton pipeline
+> * `applications.trusted-artifact-signer` — RHTAS for artifact and image signing
+> * `subscriptions.rhtas-operator` and its namespace entry
+> * `applications.trusted-profile-analyzer` — RHTPA for SBOM management
+> * `subscriptions.rhtpa-operator` and its namespace entry
+> * `applications.quay-registry` — Quay image registry (or configure an external registry)
+> * `applications.noobaa-mcg` — NooBaa MCG object storage (required by Quay and RHTPA)
+> * `subscriptions.odf` and `subscriptions.quay-operator` and their namespace entries
+>
+> If you prefer to use an external image registry instead of Quay, skip the Quay and NooBaa sections and set the registry parameters in the `supply-chain` application overrides accordingly.
+
 ## Components
 
 ### Main