Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions content/patterns/layered-zero-trust/_index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,9 @@ The pattern consists of the following key components:
* link:https://external-secrets.io[External Secrets Operator (ESO)]
** Synchronizes secrets stored in HashiCorp Vault with {ocp}.

* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14[{rh-rhacm-first}]
** Provides a management control plane in multi-cluster scenarios.

[id="sidecar-pattern"]
==== Sidecar pattern

Expand Down Expand Up @@ -119,6 +122,7 @@ The following technologies are used in this solution:
* *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.
* *{rh-rhacm}*: Provides management capabilities in multi-cluster scenarios.
* *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 show zero trust principles.
Expand Down
69 changes: 67 additions & 2 deletions content/patterns/layered-zero-trust/lzt-getting-started.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -27,10 +27,10 @@ Follow these instructions to configure and deploy the Layered Zero Trust pattern

* 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.
* Depending on the characteristics of your cluster, you might need additional hardware resources for the {rh-rhacm-first} 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].
For more details about {rh-rhacm} 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].

Expand Down Expand Up @@ -85,6 +85,11 @@ origin git@github.com:<your_username>/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)
----
+
[WARNING]
====
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.
====

. Create a local copy of the secret values file that can safely include
credentials. Run the following command:
Expand Down Expand Up @@ -177,3 +182,63 @@ The Layered Zero-Trust pattern installs the following two {ocp} GitOps instances
. **Hub Argo CD**: Manages Cluster Argo CD instance and the individual components that belong to the pattern on the hub {ocp} instance.

If every Argo CD application reports a **Healthy** status, the pattern has been deployed successfully.


[id="lzt-importing-existing-clusters"]
== Importing existing clusters

The pattern supports importing pre-existing {ocp} clusters into the Hub cluster, converting them into *Managed Clusters*.

[WARNING]
====
Do not use the `ClusterPools` configuration settings for {rh-rhacm} chart provisioning. The `ClusterPools` technology is limited to cloud environments.

Instead, use the `acm-managed-clusters` chart to import your existing standalone clusters.
====

.Procedure

. Copy the `kubeconfig` file of the cluster you want to import to your local system.

. In the `values-secret.yaml` file, define the `kubeconfig` secret by providing the local file system path to the `kubeconfig` file you copied in Step 1.
+
[source,yaml]
----
- name: kubeconfig-spoke
vaultPrefixes:
- hub
fields:
- name: content
path: ~/.kube/kubeconfig-ztvp-spoke
----

. In the `values-hub.yaml` file, add a new entry in the `clusterGroup.managedClusterGroups` key.
+
[source,yaml]
----
managedClusterGroups:
exampleRegion:
name: group-one
acmlabels:
- name: clusterGroup
value: group-one
helmOverrides:
- name: clusterGroup.isHubCluster
value: false
----

. Also in the `values-hub.yaml` file, add your cluster definition in the `acmManagedClusters.clusters` key.
+
[source,yaml]
----
acmManagedClusters:
clusters:
- name: ztvp-spoke-1
clusterGroup: group-one
labels:
cloud: auto-detect
vendor: auto-detect
kubeconfigVaultPath: secret/data/hub/kubeconfig-spoke
----

. Deploy the pattern.