diff --git a/content/patterns/layered-zero-trust/_index.adoc b/content/patterns/layered-zero-trust/_index.adoc index 1da72d2b2..bef7388de 100644 --- a/content/patterns/layered-zero-trust/_index.adoc +++ b/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. diff --git a/content/patterns/layered-zero-trust/lzt-getting-started.adoc b/content/patterns/layered-zero-trust/lzt-getting-started.adoc index dd74a538e..26c0a5b0a 100644 --- a/content/patterns/layered-zero-trust/lzt-getting-started.adoc +++ b/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. diff --git a/content/patterns/layered-zero-trust/lzt-secure-multitier.adoc b/content/patterns/layered-zero-trust/lzt-secure-multitier.adoc new file mode 100644 index 000000000..1c0d25002 --- /dev/null +++ b/content/patterns/layered-zero-trust/lzt-secure-multitier.adoc @@ -0,0 +1,103 @@ +--- +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: + + * Secrets store: Stores sensitive values for components, including PostgreSQL and RHBK. + + * Workload authentication: Implements Zero Trust Workload Identity (ZTWIM) principles by using JSON Web Token (JWT)-based authentication. 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.