Add use case and update layered zero trust docs

Author: gaurav-nelson

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

@@ -75,13 +75,21 @@ The Layered Zero Trust pattern architecture consists of many components that wor
 
 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{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 show zero trust principles.
-. PostgreSQL database: Provides the backend database for the demonstration application.
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/security_and_compliance/compliance-operator[Compliance Operator]
+** Provides {ocp} cluster hardening.
+
+* link:https://access.redhat.com/products/red-hat-build-of-keycloak/[Red{nbsp}Hat build of Keycloak (RHBK)]
+** Provides identities for pattern components.
+** Provides an OIDC client that authenticates users to a web application.
+
+* link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/security_and_compliance/zero-trust-workload-identity-manager[Red{nbsp}Hat Zero Trust Workload Identity Manager]
+** Provides identities to workloads running in {ocp}.
+
+* link:https://www.hashicorp.com/en/products/vault[HashiCorp Vault]
+** Stores sensitive assets securely.
+
+* link:https://external-secrets.io[External Secrets Operator (ESO)]
+** Synchronizes secrets stored in HashiCorp Vault with {ocp}.
 
 [id="sidecar-pattern"]
 ==== Sidecar pattern
@@ -108,7 +116,7 @@ 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{nbsp}Hat build of Keycloak (RHBK)*: Manages identity and access for users and services.
+* *Red{nbsp}Hat build of Keycloak*: 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.

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

@@ -16,13 +16,29 @@ Follow these instructions to configure and deploy the Layered Zero Trust pattern
 
 .Prerequisites
 
-* 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.
+* An {ocp} 4.19 or newer cluster with:
+
+.. publicly signed certificates for Ingress.
+.. default `StorageClass` which provides dynamic `PersistentVolume` storage.
+
+* To customize the default configuration, you must have a GitHub account and a token 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].
+* Fulfill the general link:https://validatedpatterns.io/learn/quickstart/#_prerequisites[prerequisites for Validated Patterns].
+
+* Depending on the characteristics of your cluster, you might need additional hardware resources for the Advanced Cluster Management (ACM) component.
+For a single-node cluster, you can start with 4 vCPUs, 16 GB of memory, and 120 GB of storage.
++
+For more details about ACM sizing, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14/html-single/install/index#sizing-your-cluster[Sizing your cluster].
+
+* (Optional) The Helm binary, for instructions, see link:https://helm.sh/docs/intro/install/[Installing Helm].
+
+[NOTE]
+====
+The Layered Zero Trust pattern's default deployment assumes that none of its components have been installed previously. Verify that your {ocp} environment does not already contain any of xref:/patterns/layered-zero-trust/index.html#architecture [the listed components] before proceeding.
+====
+
 
 [id="lzt-repository-setup"]
 == Repository setup
@@ -153,9 +169,11 @@ $ ./pattern.sh make install
 [id="lzt-verify-deployment"]
 === Verify the deployment
 
-You can use the {ocp} console and ArgoCD applications to verify the deployment.
+The Layered Zero-Trust pattern provisions every component and manages them through {ocp} GitOps. After you deploy the pattern, verify that all components are running correctly.
+
+The Layered Zero-Trust pattern installs the following two {ocp} GitOps instances on your Hub cluster. You can view these instances in the {ocp} web console by using the **Application Selector** (the icon with nine small squares) in the top navigation bar.
+
+. **Cluster Argo CD**: Deploys an *App-of-Apps* application named `layered-zero-trust-hub`. This application installs the pattern's components.
+. **Hub Argo CD**: Manages Cluster Argo CD instance and the individual components that belong to the pattern on the hub {ocp} instance.
 
-. 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.
+If every Argo CD application reports a **Healthy** status, the pattern has been deployed successfully.

content/patterns/layered-zero-trust/lzt-secure-multitier.adoc

@@ -0,0 +1,101 @@
+---
+title: Secure multi-tier applications
+weight: 20
+aliases: /layered-zero-trust/lzt-secure-multitier
+---
+
+:toc:
+:imagesdir: /images
+:_mod-docs-content-type: ASSEMBLY
+include::modules/comm-attributes.adoc[]
+
+[id="lzt-secure-multitier"]
+= Use case: Secure multi-tier applications
+
+This use case demonstrates securing a common application design pattern: a frontend application using a database for persistent storage.
+
+The Layered Zero Trust Pattern includes the `qtodo` application, which demonstrates a secure just-in-time (JIT) credential mechanism.
+
+Instead of relying on static credentials stored within the application, the `qtodo` application uses a JIT method to dynamically fetch database credentials from a central credential store.
+
+[id="lazt-application-architecture"]
+== Application components and architecture
+
+The `qtodo` application consists of the following key components and their security roles:
+
+* The `qtodo` application: A link:https://quarkus.io[Quarkus-based] frontend application protected by OpenID Connect (OIDC) authentication. Users are managed in an external identity store which uses Red{nbsp}Hat Build of Keycloak (RHBK).
+
+* PostgreSQL: The relational database used by the `qtodo` application. Its credentials are dynamically generated and stored within HashiCorp Vault.
+
+* External Identity store: Contains the provisioned users and configured OIDC clients that enable access to the `qtodo` frontend.
+
+* HashiCorp Vault: Stores sensitive values for components, including PostgreSQL and RHBK. Implements JSON Web Token (JWT)-based authentication to enable access by using Zero Trust Workload Identity Manager (ZTWIM)-based identities.
+
+* Zero Trust Workload Identity Manager: It assigns an identity to the `qtodo` application, allowing it to communicate with HashiCorp Vault and obtain the necessary PostgreSQL credentials.
+
+* link:https://github.com/spiffe/spiffe-helper[spiffe-helper]: A supplemental sidecar component for the `qtodo` application used to dynamically fetch JWT-based identities from the SPIFFE Workload API.
+
+[id="lzt-exploring-qtodo"]
+== Exploring the qtodo application
+
+The `qtodo` application is a key component of the Layered Zero Trust Pattern, demonstrating the secure JIT fetching of credentials. To explore how the application implements Zero Trust principles, use the {ocp} web console of the Hub cluster to investigate the resources in the `qtodo` project.
+
+.Procedure
+
+. In the {ocp} web console, navigate to the *Projects* page and select the `qtodo` project. This namespace contains the `qtodo` Quarkus application and the `qtodo-db` PostgreSQL database.
+. Select *Workloads* -> *Pods* from the left-hand navigation bar. Explore both the `qtodo` and `qtodo-db` pods.
++
+[NOTE]
+====
+The `qtodo` pod uses a series of init containers and sidecar containers to supply the application with the credentials required for operation.
+====
+
+[id="lzt-locate-app"]
+=== Locating the application address
+
+You can access the `qtodo` application through the {ocp} route.
+
+.Procedure
+
+. In the {ocp} web console, navigate to the *Projects* page and select the `qtodo` project.
+. Select *Networking* -> *Routes* from the left-hand navigation bar. Note the URL for the `qtodo` application in the *Location* column.
+. Open a new browser tab and navigate to the `qtodo` application URL.
+. The RHBK login page appears.
+
+[id="lzt-locate-app-credentials"]
+=== Locating the application credentials
+
+The default External Identity Provider, RHBK, is provisioned with two users: `qtodo-admin` and `qtodo-user`. You can find the initial credentials in a Secret within the `keycloak-system` namespace called `keycloak-users`.
+
+.Procedure
+
+. In the {ocp} web console, navigate to the *Projects* page and select the `keycloak-system` project.
+. Select *Workloads* -> *Secrets* from the left-hand navigation bar.
+. Select the `keycloak-users` secret.
+. Click the *Reveal values* link to see the credentials.
+
+[id="lzt-access-qtodo"]
+=== Accessing the application
+
+.Procedure
+
+. Navigate to the RHBK login page, as described in the xref:lzt-locate-app[Locate the application's address] section.
+
+. Enter the username and password for one of the users, using the values found in the xref:lzt-locate-app-credentials[Locate the application credentials] section.
+
+. After you log in, follow the on-screen instructions to change the temporary password.
+
+. Set a new password and confirm the change.
++
+After the password change is complete, the `qtodo` application appears.
+
+[id="lzt-verify-integration"]
+=== Verifying integration
+
+The `qtodo` application uses PostgreSQL for persistent storage. You can verify that the application is correctly integrated with the database by creating a new to-do item.
+
+.Procedure
+. In the `qtodo` application, add new items to the list of to-dos and remove existing items.
+. Refresh the page to verify that the items persist.
+
+By successfully modifying the list, you confirm that the integration between the Quarkus application and the PostgreSQL database—using credentials sourced dynamically from HashiCorp Vault—was successful.