diff --git a/.wordlist.txt b/.wordlist.txt index 59d12a1a6..68a3cfd7c 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -1,3 +1,4 @@ + aaaee aab aap @@ -14,7 +15,6 @@ additionalimages addon addons addr -addr adoc ae aeg @@ -39,9 +39,9 @@ anattama anonymized anonymizer ansible +api's apicast apicurito -api's apis apiversion appdev @@ -107,7 +107,9 @@ byo cacert cakephp canarypausestep +cas cdd +cdh cdn centos centric @@ -155,11 +157,13 @@ cmzwn cncf cnv cockroachdb +coco codepath coffeeshop colocated compliancetype conf +confidentialcontainers config configmanagement configmap @@ -171,6 +175,7 @@ containerimage controlplane controlplaneendpoint coreos +cosign cp crd crds @@ -192,6 +197,7 @@ ctrl cuda customerloyalty customermocker +customise customizable customizations cves @@ -413,6 +419,7 @@ hybridcloudpatterns hyperconverged hyperscaler hypershift +hyperthreading iaa iam ib @@ -420,6 +427,7 @@ ibmcloud idempotence idms idp +ietf iframe ignoredifferences iio @@ -504,6 +512,9 @@ kam kamelet kasten kastendr +kata +katacontainers +kbs keycloak keypair keypairs @@ -563,6 +574,7 @@ lsv lvm lvms machineapi +machineconfig machineconfigpool machineconfigs machineset @@ -618,6 +630,7 @@ mq mqtt multicloud multicluster +multiclusterhub multisource multisourceconfig musthave @@ -686,8 +699,8 @@ opendatahub openid openjdk openshift -openshiftpullsecret openshift's +openshiftpullsecret openshiftsdn openshiftversion openssl @@ -700,6 +713,7 @@ operatorgroups operatorhub operatorsource opr +osc osspa osx ouput @@ -722,6 +736,7 @@ patternsh patternsoperator pbivukilnpoe pci +pcr pem performant persistentvolumeclaim @@ -787,6 +802,7 @@ querier quickassist quickstart rabbitmq +raci rbac rbklxs rdma @@ -803,8 +819,8 @@ renderers replicaset replicasets repo -repolist repo's +repolist repos repourl reranked @@ -847,6 +863,7 @@ runtimes rxpm saas saml +sandboxed sas sbom scada @@ -880,6 +897,7 @@ signin sigstore siteadmin skipdryrunonmissingresource +skopeo sla slas sme @@ -939,6 +957,7 @@ targetport tbd tcp techpreview +tee tei tekron tekton @@ -984,6 +1003,7 @@ tradeoff tradeoffs transactional travelops +trustee trvlops tsa tst @@ -1002,8 +1022,8 @@ unsealvault untrusted updatingconfig updatingversion -upstreaming upstream's +upstreaming ure uri usecsv diff --git a/content/patterns/coco-pattern/_index.adoc b/content/patterns/coco-pattern/_index.adoc index 80fe4d9a5..e3a13c6d2 100644 --- a/content/patterns/coco-pattern/_index.adoc +++ b/content/patterns/coco-pattern/_index.adoc @@ -25,48 +25,59 @@ include::modules/comm-attributes.adoc[] = About the Confidential Containers pattern -Confidential computing is a technology for securing data in use. It uses a https://en.wikipedia.org/wiki/Trusted_execution_environment[Trusted Execution Environment] provided within the hardware of the processor to prevent access from others who have access to the system. -https://confidentialcontainers.org/[Confidential containers] is a project to standardize the consumption of confidential computing by making the security boundary for confidential computing to be a Kubernetes pod. https://katacontainers.io/[Kata containers] is used to establish the boundary via a shim VM. +Confidential computing is a technology for securing data in use. It uses a https://en.wikipedia.org/wiki/Trusted_execution_environment[Trusted Execution Environment] (TEE) provided within the hardware of the processor to prevent access from others who have access to the system, including cluster administrators and hypervisor operators. +https://confidentialcontainers.org/[Confidential containers] is a project to standardize the consumption of confidential computing by making the security boundary for confidential computing a Kubernetes pod. https://katacontainers.io/[Kata containers] is used to establish the boundary via a shim VM. -A core goal of confidential computing is to use this technology to isolate the workload from both Kubernetes and hypervisor administrators. +A core goal of confidential computing is to use this technology to isolate the workload from both Kubernetes and hypervisor administrators. In practice this means that even a `kubeadmin` user cannot `exec` into a running confidential container or inspect its memory. -image::coco-pattern/isolation.png[Schematic describing the isolation of confidential contains from the hosting system] +image::coco-pattern/isolation.png[Schematic describing the isolation of confidential containers from the hosting system] -This pattern uses https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7/html/user_guide/deploying-on-azure#deploying-cc_azure-cc[Red Hat OpenShift sandbox containers] to deploy and configure confidential containers on Microsoft Azure. +This pattern uses https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/cc-overview[Red Hat OpenShift sandbox containers] to deploy and configure confidential containers on Microsoft Azure. On Azure, confidential containers run as "peer pods" — VMs from the `Standard_DCas_v5` family provisioned directly on the Azure hypervisor rather than nested inside OpenShift worker nodes. -It deploys three copies of 'Hello OpenShift' to demonstrate some of the security boundaries that enforced with confidential containers. +It deploys three copies of 'Hello OpenShift' to demonstrate some of the security boundaries enforced with confidential containers, along with a `kbs-access` application that verifies end-to-end secret delivery from the Key Broker Service. == Requirements -- An an azure account with the link:./coco-pattern-azure-requirements/[required access rights] -- An OpenShift cluster, within the Azure environment updated beyond 4.16.10 +- An Azure account with the link:./coco-pattern-azure-requirements/[required access rights], including quota for `Standard_DCas_v5` confidential VMs +- An OpenShift 4.17+ cluster within the Azure environment +- Tools: `podman`, `yq`, `jq`, `skopeo` +- An OpenShift pull secret at `~/pull-secret.json` == Security considerations **This pattern is a demonstration only and contains configuration that is not best practice** -- The default configuration deploys everything in a single cluster for testing purposes. The https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html[RATS] architecture mandates that the Key Broker Service (e.g. https://github.com/confidential-containers/trustee[Trustee]) is in a trusted security zone. -- The https://github.com/confidential-containers/trustee/tree/main/attestation-service[Attestation Service] has wide open security policies. +- The pattern supports both single-cluster (`simple` clusterGroup) and multi-cluster (`trusted-hub` + `spoke`) topologies. The default is single-cluster, which breaks the RACI separation expected in a remote attestation architecture. In the single-cluster topology, the Key Broker Service and the workloads it protects run on the same cluster, meaning a compromised cluster could affect both. The multi-cluster topology addresses this by separating the trusted zone (Trustee, Vault, ACM on the hub) from the untrusted workload zone (spoke). The https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html[RATS] architecture mandates that the Key Broker Service (e.g. https://github.com/confidential-containers/trustee[Trustee]) is in a trusted security zone. +- The https://github.com/confidential-containers/trustee/tree/main/attestation-service[Attestation Service] has wide open security policies. The default `insecure` policy accepts all images without signature verification. For production use, configure the `signed` policy in `values-secret.yaml.template` and provide cosign public keys. == Future work -* Deploying the environment the 'Trusted' environment including the KBS on a separate cluster to the secured workloads * Deploying to alternative environments supporting confidential computing including bare metal x86 clusters; IBM Cloud; IBM Z -* Finishing the sample AI application +* Finishing the sample AI application for confidential inference with protected GPUs +* Supporting air-gapped deployments == Architecture -Confidential Containers typically has two environments. A trusted zone, and an untrusted zone. In these zones, Trustee, and the sandbox container operator are deployed, respectively. +Confidential Containers typically has two environments. A trusted zone, and an untrusted zone. In the trusted zone, the Key Broker Service (Trustee), attestation service, and secrets management (Vault) are deployed. In the untrusted zone, the sandboxed containers operator provisions confidential VMs and runs workloads. -** For demonstration purposes the pattern currently is converged on one cluster** +The pattern supports both single-cluster and multi-cluster topologies. In the single-cluster topology (`simple` clusterGroup), all components are converged on one cluster. In the multi-cluster topology, the `trusted-hub` clusterGroup runs on the hub cluster and the `spoke` clusterGroup runs on one or more managed clusters imported via ACM. See link:./coco-pattern-getting-started/[Getting started] for deployment options. image::coco-pattern/overview-schematic.png[Schematic describing the high level architecture of confidential containers] +=== Key components +- **Red Hat Build of Trustee 1.0**: The Key Broker Service (KBS) and attestation service. Trustee verifies that workloads are running in a genuine TEE before releasing secrets. Certificates for Trustee are managed by cert-manager using self-signed CAs. +- **HashiCorp Vault**: Secrets backend for the Validated Patterns framework. Stores KBS keys, attestation policies, and PCR measurements. +- **OpenShift Sandboxed Containers 1.11**: Deploys and manages peer-pod VMs for confidential workloads. Operator subscriptions are pinned to specific CSV versions with manual install plan approval to ensure version consistency. +- **Red Hat Advanced Cluster Management (ACM)**: Manages the spoke cluster in multi-cluster deployments. Policies and applications are deployed to the spoke via ACM's application lifecycle management. == References -- https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7/html/user_guide/about-osc#about-confidential-containers_about-osc[OpenShift sandboxed containers documentation] +- https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11[OpenShift Sandboxed Containers 1.11 documentation] +- https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/cc-overview[Deploying confidential containers on OpenShift] +- https://docs.redhat.com/en/documentation/red_hat_build_of_trustee/1.0[Red Hat Build of Trustee 1.0 documentation] +- https://www.redhat.com/en/blog/red-hat-openshift-sandboxed-containers-111-and-red-hat-build-trustee-10-accelerate-confidential-computing-across-hybrid-cloud[OSC 1.11 and Trustee 1.0 announcement blog] - https://www.redhat.com/en/blog/exploring-openshift-confidential-containers-solution[OpenShift confidential containers solution blog] +- https://www.redhat.com/en/blog/introducing-confidential-containers-trustee-attestation-services-solution-overview-and-use-cases[Trustee attestation services overview] diff --git a/content/patterns/coco-pattern/coco-pattern-azure-requirements.adoc b/content/patterns/coco-pattern/coco-pattern-azure-requirements.adoc index 4f2813a5c..b35040029 100644 --- a/content/patterns/coco-pattern/coco-pattern-azure-requirements.adoc +++ b/content/patterns/coco-pattern/coco-pattern-azure-requirements.adoc @@ -11,16 +11,15 @@ include::modules/comm-attributes.adoc[] :imagesdir: ../../../images = Azure requirements -This demo currently has been tested only on azure. -The configuration tested used the `openshift-install`. -https://docs.openshift.com/container-platform/4.16/installing/installing_azure/installing-azure-default.html[OpenShift documentation] contains details on how to do this. +This pattern has been tested on Microsoft Azure using self-managed OpenShift clusters provisioned with `openshift-install`. +https://docs.openshift.com/container-platform/4.17/installing/installing_azure/installing-azure-default.html[OpenShift documentation] contains details on how to install a cluster on Azure. -The documentation outlines https://docs.openshift.com/container-platform/4.16/installing/installing_azure/installing-azure-account.html[minimum required configuration] for an azure account. +The documentation outlines the https://docs.openshift.com/container-platform/4.17/installing/installing_azure/installing-azure-account.html[minimum required configuration] for an Azure account. == Changes required -Do not accept default sizes for OpenShift install. It is recommended to up the workers to at least `Standard_D8s_v5`. -This can be done by using `openshift-install create install-config` first and adjusting the workers under platform e.g.: +Do not accept default sizes for OpenShift install. It is recommended to increase the worker node size to at least `Standard_D8s_v5`. +This can be done by using `openshift-install create install-config` first and adjusting the workers under platform, for example: [source,yaml] ---- @@ -35,29 +34,31 @@ This can be done by using `openshift-install create install-config` first and ad On a cloud provider the virtual machines for the kata containers use "peer pods" which are running directly on the cloud provider's hypervisor (see the diagram below). This means that access is required to the "confidential computing" virtual machine class. On Azure the `Standard_DCas_v5` class of virtual machines are used. -These virtual machines are *NOT* available in all regions. Users will also need to up the specific limits for `Standard_DC2as_v5` virtual machines. +These virtual machines are *NOT* available in all regions. Check https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/[Azure products by region] to confirm availability in your target region. + +Users will also need to request quota increases for the `Standard_DC2as_v5` (and optionally `Standard_DC4as_v5`, `Standard_DC8as_v5`, `Standard_DC16as_v5`) virtual machine families in their target region. By default, Azure subscriptions may have zero quota for confidential computing VM sizes. image::coco-pattern/peer_pods.png[Schematic diagram of peer pods vs standard kata containers] -DNS for the openshift cluster also *MUST* be provided by azure DNS. +DNS for the OpenShift cluster *MUST* be provided by Azure DNS. The pattern uses Azure DNS for both the cluster's ingress and for cert-manager DNS01 challenge validation when issuing certificates. == Azure configuration required for the validated pattern -The validated pattern requires access to azure apis to provision peer-pod VMs and to obtain certificates from let's encrypt. +The validated pattern requires access to Azure APIs to provision peer-pod VMs. Azure configuration information must be provided in two places: -- The a secret must be loaded using a ../../../learn/secrets-management-in-the-validated-patterns-framework/[values-secret] file. - The https://github.com/validatedpatterns/coco-pattern/blob/main/values-secret.yaml.template[`values-secret.yaml.template`] file provides the appropriate structure +- A secret must be loaded using a ../../../learn/secrets-management-in-the-validated-patterns-framework/[values-secret] file. + The https://github.com/validatedpatterns/coco-pattern/blob/main/values-secret.yaml.template[`values-secret.yaml.template`] file provides the appropriate structure. The Azure client secret (service principal password) is stored here and loaded into Vault. -- A broader set of information about the cluster is required in https://github.com/validatedpatterns/coco-pattern/blob/main/values-global.yaml[`values-global.yaml`] (see below). +- A broader set of information about the cluster is required in https://github.com/validatedpatterns/coco-pattern/blob/main/values-global.yaml[`values-global.yaml`] (see below). These values are used by the sandboxed containers operator to provision peer-pod VMs in the correct Azure subscription, resource group, and virtual network. [source,yaml] ---- global: azure: - clientID: '' # Service principle ID + clientID: '' # Service principal ID subscriptionID: '' tenantID: '' # Tenant ID DNSResGroup: '' # Resource group for the azure DNS hosted zone @@ -68,3 +69,4 @@ global: clusterRegion: '' ---- +The `clusterResGroup`, `clusterSubnet`, and `clusterNSG` values can be found in the Azure portal after the cluster has been provisioned, or via `openshift-install` metadata. The `DNSResGroup` and `hostedZoneName` correspond to the Azure DNS zone used for the cluster's base domain. diff --git a/content/patterns/coco-pattern/coco-pattern-getting-started.adoc b/content/patterns/coco-pattern/coco-pattern-getting-started.adoc index 2f71002de..8aa046e63 100644 --- a/content/patterns/coco-pattern/coco-pattern-getting-started.adoc +++ b/content/patterns/coco-pattern/coco-pattern-getting-started.adoc @@ -12,75 +12,104 @@ include::modules/comm-attributes.adoc[] == Deploying -1. Install an link:../coco-pattern-azure-requirements/[OpenShift Cluster on Azure] +=== Prerequisites -2. Update the link:../coco-pattern-azure-requirements/#_azure_configuration_required_for_the_validated_pattern[required Azure configuration and secrets] +1. Install an link:../coco-pattern-azure-requirements/[OpenShift 4.17+ Cluster on Azure] -3. `./pattern.sh make install` +2. Update the link:../coco-pattern-azure-requirements/#_azure_configuration_required_for_the_validated_pattern[required Azure configuration and secrets] in `values-global.yaml`, including the Azure service principal, DNS resource group, and cluster networking details. -4. Wait: The cluster needs to reboot all nodes at least once, and reprovision the ingress to use the let's encrypt certificates. +3. Fork the repository and clone it locally. ArgoCD reconciles against your fork, so all configuration changes must be committed and pushed. -5. If the services do not come up use the ArgoCD UI to triage potential timeouts. +4. Run `bash scripts/gen-secrets.sh` to generate KBS key pairs, attestation policy seeds, and copy the values-secret template to `~/values-secret-coco-pattern.yaml`. This script will not overwrite existing secrets. + +5. Run `bash scripts/get-pcr.sh` to retrieve PCR measurements from the peer-pod VM image. This stores the measurements at `~/.coco-pattern/measurements.json`, which are loaded into Vault and used by the attestation service. Requires `podman`, `skopeo`, and a pull secret at `~/pull-secret.json`. + +6. Review and customise `~/values-secret-coco-pattern.yaml`. This file controls what secrets are loaded into Vault, including attestation policies, KBS key material, and PCR measurements. See the comments in `values-secret.yaml.template` for details on each field. + +=== Single cluster deployment + +The single-cluster topology uses the `simple` clusterGroup. All components — Trustee, Vault, ACM, sandboxed containers, and workloads — are deployed on one cluster. + +1. Ensure `main.clusterGroupName: simple` is set in `values-global.yaml` + +2. `./pattern.sh make install` + +3. Wait for the cluster to reboot all nodes. The sandboxed containers operator applies a MachineConfig update that triggers a rolling reboot. Monitor progress via the ArgoCD UI or `oc get nodes`. + +4. If the services do not come up, use the ArgoCD UI to triage potential timeouts. Peer-pod VMs may need to be restarted if they time out during initial provisioning. + +=== Multi-cluster deployment + +The multi-cluster topology separates the trusted zone (hub) from the untrusted workload zone (spoke). The hub cluster runs Trustee, Vault, and ACM. The spoke cluster runs the sandboxed containers operator and confidential workloads. + +1. Set `main.clusterGroupName: trusted-hub` in `values-global.yaml` + +2. Deploy the hub cluster: `./pattern.sh make install` + +3. Wait for ACM (`MultiClusterHub`) to reach `Running` state on the hub cluster: `oc get multiclusterhub -n open-cluster-management` + +4. Provision a second OpenShift 4.17+ cluster on Azure for the spoke + +5. Import the spoke cluster into ACM with the label `clusterGroup=spoke` (see https://validatedpatterns.io/learn/importing-a-cluster/[importing a cluster]). ACM will automatically deploy the `spoke` clusterGroup applications to the imported cluster. + +6. The spoke cluster will install the sandboxed containers operator, deploy peer-pod infrastructure, and launch the sample workloads. Monitor progress in the ACM console or via ArgoCD on the spoke. == Simple Confidential container tests -The pattern deploys some simple tests of CoCo with this pattern. -A "Hello Openshift" (e.g. `curl` to return "Hello Openshift!") application has been deployed in three form factor. +The pattern deploys some simple tests of CoCo with this pattern. +A "Hello Openshift" (e.g. `curl` to return "Hello Openshift!") application has been deployed in three configurations: -1. A vanilla kubernetes pod at `oc get pods -n hello-openshift standard` -2. A confidential container `oc get pods -n hello-openshift secure` -3. A confidential container with a relaxed policy at `oc get pods -n hello-openshift insecure-policy` +1. A vanilla kubernetes pod: `oc get pods -n hello-openshift standard` +2. A confidential container with a strict policy: `oc get pods -n hello-openshift secure` +3. A confidential container with a relaxed policy: `oc get pods -n hello-openshift insecure-policy` -In this case the insecure policy is designed to allow a user to be able to exec into the confidential container. +In this case the insecure policy is designed to allow a user to be able to exec into the confidential container. Typically this is disabled by an immutable policy established at pod creation time. - -Doing a `oc get pods` for either of the pods running a confidential container should show the `runtimeClassName: kata-remote` for the pod. +Doing `oc get pod -n hello-openshift secure -o yaml` for either of the pods running a confidential container should show `runtimeClassName: kata-remote`, confirming it is running as a peer-pod. // Add a azure portal image grab next boot -Logging into azure once the pods have been provisioned will show that each of these two pods has been provisioned with it's own `Standard_DC2as_v5` virtual machine. +Logging into the Azure portal once the pods have been provisioned will show that each of these two confidential pods has been provisioned with its own `Standard_DC2as_v5` virtual machine. These VMs are visible under the cluster's resource group. === `oc exec` testing -In a OpenShift cluster without confidential containers, Role Based Access Control (RBAC), may be used to prevent users from using `oc exec` to access a container container to mutate it. +In an OpenShift cluster without confidential containers, Role Based Access Control (RBAC) may be used to prevent users from using `oc exec` to access a container to mutate it. However: 1. Cluster admins can always circumvent this capability -2. Anyone logged into the node directly can also circumvent this capability. +2. Anyone logged into the node directly can also circumvent this capability -Confidential containers can prevent this. Running: `oc exec -n hello-openshift -it secure -- bash` will result in a denial of access, irrespective of the user undertaking the action, including `kubeadmin`. -For running this with either the standard pod `oc exec -n hello-openshift -it standard -- bash`, or the CoCo pod with the policy disabled `oc exec -n hello-openshift -it insecure-policy -- bash` will allow shell access. +Confidential containers enforce this boundary at the hardware level, independent of RBAC. Running: `oc exec -n hello-openshift -it secure -- bash` will result in a denial of access, irrespective of the user undertaking the action, including `kubeadmin`. The policy is baked into the pod at creation time and cannot be modified at runtime. + +For comparison, `oc exec -n hello-openshift -it standard -- bash` (the standard pod) and `oc exec -n hello-openshift -it insecure-policy -- bash` (the CoCo pod with a relaxed policy) will both allow shell access. === Confidential Data Hub testing -Part of the CoCo VM is a component called the Confidential Data Hub (CDH), which simplifies access to the Trustee Key Broker service for end applications. +Part of the CoCo VM is a component called the Confidential Data Hub (CDH), which simplifies access to the Trustee Key Broker Service (KBS) for end applications. The CDH runs inside the confidential VM and handles attestation transparently — applications simply make HTTP requests to a localhost endpoint. + Find out more about how the CDH and Trustee work together https://www.redhat.com/en/blog/introducing-confidential-containers-trustee-attestation-services-solution-overview-and-use-cases[here]. image::coco-pattern/trustee.png[] -The CDH presents to containers within the pod (only), via a localhost URL. The CoCo container with an insecure policy can be used for testing the behaviour. +The CDH presents to containers within the pod (only), via a localhost URL. The CoCo container with an insecure policy can be used for testing the behaviour, since it allows `oc exec`. - `oc exec -n hello-openshift -it insecure-policy -- bash` to get a shell into a confidential container -- https://github.com/validatedpatterns/coco-pattern/blob/main/charts/hub/trustee/templates/kbs.yaml[Trustee's configuration] specifies the list of secrets which the KBS can access with the `kbsSecretResources` attribute. +- https://github.com/butler54/trustee-chart[Trustee's configuration] specifies the list of secrets which the KBS can access with the `kbsSecretResources` attribute. These are mapped to Vault paths (e.g. `secret/data/hub/kbsres1`). - Secrets within the CDH can be accessed (by default) at `http://127.0.0.1:8006/cdh/resource/default/$K8S_SECRET/$K8S_SECRET_KEY`. - In this case `http://127.0.0.1:8006/cdh/resource/default/passphrase/passphrase` by default will return a string which was randomly generated when the pattern was deployed. -- This should be the same as result as `oc get secrets -n trustee-operator-system passphrase -o yaml | yq '.data.passphrase'` | base64 -d` - -- Tailing the logs for the kbs container e.g. `oc logs -n trustee-operator-system kbs-deployment-5b574bccd6-twjxh -f` shows the evidence which is flowing to the KBS from the CDH. - - - - - - +- To verify, compare the CDH output against the Vault-backed secret: `oc get secrets -n trustee-operator-system passphrase -o yaml | yq '.data.passphrase' | base64 -d`. The values should match. +- Tailing the logs for the KBS container (e.g. `oc logs -n trustee-operator-system -l app=kbs -f`) shows the attestation evidence flowing from the CDH to the KBS, including TEE evidence validation. +=== kbs-access application +The `kbs-access` application is a web service deployed in the `kbs-access` namespace. It retrieves secrets from Trustee via the CDH and presents them through a web interface. This provides a convenient way to verify that the full attestation pipeline is working end-to-end without needing to exec into a pod. +Access the application via its OpenShift route: `oc get route -n kbs-access`. diff --git a/content/patterns/coco-pattern/coco-pattern-tested-environments.adoc b/content/patterns/coco-pattern/coco-pattern-tested-environments.adoc new file mode 100644 index 000000000..dd2ec95c3 --- /dev/null +++ b/content/patterns/coco-pattern/coco-pattern-tested-environments.adoc @@ -0,0 +1,70 @@ +--- +title: CoCo pattern tested environments +weight: 10 +aliases: /coco-pattern/coco-pattern-tested-environments/ +--- + + +:_content-type: ASSEMBLY +include::modules/comm-attributes.adoc[] + +:imagesdir: ../../../images + += Tested environments + +== Current version (4.*) + +Version 4 is the first release of the pattern using Generally Available (GA) versions of the CoCo stack. All prior versions used Technology Preview releases of Trustee. + +=== Supported components +- OpenShift Sandboxed Containers Operator 1.11 +- Red Hat Build of Trustee 1.0 (first GA release) +- OpenShift Container Platform 4.17+ +- cert-manager operator (stable-v1 channel) +- Red Hat Advanced Cluster Management (for multi-cluster topology) +- HashiCorp Vault (secrets management) + +=== Single cluster +Tested on Azure with the `simple` clusterGroup using self-managed OpenShift provisioned via `openshift-install`. In this topology all components — Trustee, Vault, ACM, sandboxed containers operator, and sample workloads — are deployed on a single cluster. + +Worker nodes use `Standard_D8s_v5` or larger. Peer-pod VMs for confidential containers use `Standard_DC2as_v5` from the Azure confidential computing VM family. Azure DNS is required for the cluster's hosted zone. + +=== Multiple clusters +Tested with `trusted-hub` + `spoke` clusterGroups on Azure, both using self-managed OpenShift. + +- `trusted-hub`: Vault, ACM, Trustee (KBS + attestation service), cert-manager. This cluster acts as the trust anchor and ACM hub. +- `spoke`: Sandboxed containers operator, peer-pod infrastructure, and sample workloads (hello-openshift, kbs-access). Imported into ACM with the `clusterGroup=spoke` label. + +The spoke cluster connects back to the hub's Trustee instance for attestation and secret retrieval. Secrets are synchronised from the hub's Vault to the spoke via the External Secrets operator. + +== Version history + +All pattern versions prior to v4 used Technology Preview (pre-GA) releases of Trustee. Version 4 is a breaking change that moves to GA components and adds multi-cluster support. + +|=== +| Pattern version | Trustee | OSC | Min OCP | Notes + +| 4.* (current) +| 1.0 (GA) +| 1.11 +| 4.17 +| First GA release. Multi-cluster support. cert-manager replaces Let's Encrypt. + +| 3.* +| 0.4.* (Tech Preview) +| 1.10.* +| 4.16 +| Single cluster only. Tested on Azure (self-managed and ARO). + +| 2.* +| 0.3.* (Tech Preview) +| 1.9.* +| 4.16 +| Single cluster only. Tested on Azure (self-managed and ARO). + +| 1.0.0 +| 0.2.0 (Tech Preview) +| 1.8.1 +| 4.16 +| Initial release. Single cluster only. Self-managed OpenShift on Azure. +|===