feat: externalize the core charts

README.md

@@ -2,28 +2,30 @@
 
 This is a validated pattern for deploying confidential containers on OpenShift.
 
-The target operating model has two clusters:
+There are two topologies for deploying this pattern:
 
-- One in a "trusted" zone where the remote attestation, KMS and Key Broker infrastructure are deployed.
-- A second where a subset of workloads are deployed in confidential containers.
+1. *Default* using a single cluster. This breaks the RACI expected in a remote attestation architecture, however, makes it easier to test. This uses the `simple` `clusterGroup`.
+2. A more secure operating model that has two clusters:
+   - One in a "trusted" zone where the remote attestation, KMS and Key Broker infrastructure are deployed. This is also the Advanced Cluster Manager Hub cluster. It uses the `trusted-hub` `clusterGroup`.
+   - A second where a subset of workloads are deployed in confidential containers. It uses the `spoke` `clusterGroup`
 
 The current version of this application the confidential containers assumes deployment to Azure.
 
-On the platform a sample workload is deployed:
+On the cluster where confidential workloads are deployed two sample applications are deployed:
 
 1. Sample hello world applications to allow users to experiment with the policies for CoCo and the KBS (trustee).
 2. A sample application `kbs-access` which presents secrets obtained from trustee to a web service. This is designed to allow users to test locked down environments.
 
 Future work includes:
 
-1. Supporting a multiple cluster deployment
-2. Supporting multiple infrastructure providers
-3. Supporting a more sophisticated workload such as confidential AI inference with protected GPUs.
+1. ~~Supporting a multiple cluster deployment~~ Done
+2. Supporting multiple infrastructure providers - Work in Progress.
+3. Supporting air-gapped deployments - Work in Progress.
+4. Supporting a more sophisticated workload such as confidential AI inference with protected GPUs.
 
 ## Current constraints and assumptions
 
 - Only currently is known to work with `azure` as the provider of confidential vms via peer-pods.
-- Only known to work today with everything on one cluster. The work to expand this is in flight.
 - Below version 3.1, if not using ARO you must either provide your own CA signed certs, or use let's encrypt.
 - Must be on 4.16.14 or later.
 
@@ -61,9 +63,6 @@ The pattern has been tested on Azure for two installation methods:
 1. Installing onto an ARO cluster
 2. Self managed OpenShift install using the `openshift-install` CLI.
 
-> [!IMPORTANT]
-> You need an external CA signed certificate for to be added (e.g. with let's encrypt) to a self-managed install
-
 ### `1.0.0`
 
 1.0.0 supports OpenShift Sandboxed containers version `1.8.1` along with Trustee version `0.2.0`.
@@ -73,18 +72,15 @@ The pattern has been tested on Azure for one installation method:
 1. Self managed OpenShift install using the `openshift-install` CLI
 2. Installing on top of an existing Azure Red Hat OpenShift (ARO) cluster
 
-## Validated pattern flavours
+## Changing deployment topoloiges
 
-**Today the demo has one flavour**.
-A number are planned based on various different hub cluster-groups.
-You can change between behaviour by configuring [`global.main.clusterGroupName`](https://validatedpatterns.io/learn/values-files/) key in the `values-global.yaml` file.
+**Today the demo has two deployment topologies**
+The most important change is what `clusterGroup` is deployed to your main or 'hub' cluster.
 
-`values-simple.yaml`: or the `simple` cluster group is the default for the pattern.
-It deploys a hello-openshift application 3 times:
+You can change between behaviour by configuring [`global.main.clusterGroupName`](https://validatedpatterns.io/learn/values-files/) key in the `values-global.yaml` file.
 
-- A standard pod
-- A kata container with peer-pods
-- A confidential kata-container
+- `values-simple.yaml`: or the `simple` cluster group is the default for the pattern. It deploys everything in one cluster.
+-`values-trusted-hub`: or the `trusted-hub` cluster group can be configured as the main cluster group. A second cluster should be deployed with the `spoke` cluster group. Follow [instructions here](https://validatedpatterns.io/learn/importing-a-cluster/) to add the second cluster.
 
 ## Setup instructions
 
@@ -110,12 +106,12 @@ This only has to be done once.
 > [!NOTE]
 > Once generated this script will not override secrets. Be careful when doing multiple tests.
 
-#### Configuring let's encrypt
+#### Configuring let's encrypt (deprecated)
 
 > [!IMPORTANT]
 > Ensure you have password login available to the cluster. Let's encrypt will replace the API certificate in addition to the certificates to user with routes.
 
-Trustee requires a trusted CA issued certificate. Let's Encrypt is included for environments without a trusted cert on OpenShift's routes.
+Trustee (guest agents) requires that Trustee uses a Mozilla trusted CA issued certificate, or a specific certificate which is known in advance. Today the pattern uses specific self signed certs. Let's encrypt was an option for getting a trusted certificate onto OpenShift's routes, and therefore Trustee. Ths functionality will be removed at a later date.
 
 If you need a Let's Encrypt certificate to be issued the `letsencrypt` application configuration needs to be changed as below.
 

ansible/initdata-default.toml.tpl

@@ -5,10 +5,10 @@ version = "0.1.0"
 "aa.toml" = '''
 [token_configs]
 [token_configs.coco_as]
-url = "https://kbs-trustee-operator-system.{{ hub_domain }}"
+url = "https://kbs.{{ hub_domain }}"
 
 [token_configs.kbs]
-url = "https://kbs-trustee-operator-system.{{ hub_domain }}"
+url = "https://kbs.{{ hub_domain }}"
 cert = """
 {{ trustee_cert }}
 """
@@ -20,7 +20,7 @@ credentials = []
 
 [kbc]
 name = "cc_kbc"
-url = "https://kbs-trustee-operator-system.{{ hub_domain }}"
+url = "https://kbs.{{ hub_domain }}"
 kbs_cert = """ 
 {{ trustee_cert }}
 """