You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Update CoCo pattern docs for v4 GA release (Trustee 1.0, OSC 1.11)
Update confidential containers pattern documentation for the v4 GA release:
- Upgrade component versions: Trustee 1.0, OSC 1.11, OCP 4.17+
- Add multi-cluster deployment support with ACM/MCH
- Add new tested environments and version history page
- Update Azure requirements with terminology and guidance fixes
- Add missing technical terms to spellcheck wordlist
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.
29
-
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.
28
+
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.
29
+
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.
30
30
31
-
A core goal of confidential computing is to use this technology to isolate the workload from both Kubernetes and hypervisor administrators.
31
+
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.
32
32
33
-
image::coco-pattern/isolation.png[Schematic describing the isolation of confidential contains from the hosting system]
33
+
image::coco-pattern/isolation.png[Schematic describing the isolation of confidential containers from the hosting system]
34
34
35
35
36
-
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.
36
+
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.
37
37
38
-
It deploys three copies of 'Hello OpenShift' to demonstrate some of the security boundaries that enforced with confidential containers.
38
+
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.
39
39
40
40
== Requirements
41
41
42
-
- An an azure account with the link:./coco-pattern-azure-requirements/[required access rights]
43
-
- An OpenShift cluster, within the Azure environment updated beyond 4.16.10
42
+
- An Azure account with the link:./coco-pattern-azure-requirements/[required access rights], including quota for `Standard_DCas_v5` confidential VMs
43
+
- An OpenShift 4.17+ cluster within the Azure environment
44
+
- Tools: `podman`, `yq`, `jq`, `skopeo`
45
+
- An OpenShift pull secret at `~/pull-secret.json`
44
46
45
47
46
48
== Security considerations
47
49
48
50
**This pattern is a demonstration only and contains configuration that is not best practice**
49
51
50
-
- The default configuration deploys everything in a singlecluster 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.
51
-
- The https://github.com/confidential-containers/trustee/tree/main/attestation-service[Attestation Service] has wide open security policies.
52
+
- 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.
53
+
- 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.
52
54
53
55
== Future work
54
56
55
-
* Deploying the environment the 'Trusted' environment including the KBS on a separate cluster to the secured workloads
56
57
* Deploying to alternative environments supporting confidential computing including bare metal x86 clusters; IBM Cloud; IBM Z
57
-
* Finishing the sample AI application
58
+
* Finishing the sample AI application for confidential inference with protected GPUs
59
+
* Supporting air-gapped deployments
58
60
59
61
== Architecture
60
62
61
-
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.
63
+
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.
62
64
63
-
** For demonstration purposes the pattern currently is converged on one cluster**
65
+
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.
64
66
65
67
image::coco-pattern/overview-schematic.png[Schematic describing the high level architecture of confidential containers]
66
68
69
+
=== Key components
67
70
71
+
- **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.
72
+
- **HashiCorp Vault**: Secrets backend for the Validated Patterns framework. Stores KBS keys, attestation policies, and PCR measurements.
73
+
- **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.
74
+
- **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.
This demo currently has been tested only on azure.
15
-
The configuration tested used the `openshift-install`.
16
-
https://docs.openshift.com/container-platform/4.16/installing/installing_azure/installing-azure-default.html[OpenShift documentation] contains details on how to do this.
14
+
This pattern has been tested on Microsoft Azure using self-managed OpenShift clusters provisioned with `openshift-install`.
15
+
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.
17
16
18
-
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.
17
+
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.
19
18
20
19
== Changes required
21
20
22
-
Do not accept default sizes for OpenShift install. It is recommended to up the workers to at least `Standard_D8s_v5`.
23
-
This can be done by using `openshift-install create install-config` first and adjusting the workers under platform e.g.:
21
+
Do not accept default sizes for OpenShift install. It is recommended to increase the worker node size to at least `Standard_D8s_v5`.
22
+
This can be done by using `openshift-install create install-config` first and adjusting the workers under platform, for example:
24
23
25
24
[source,yaml]
26
25
----
@@ -35,29 +34,31 @@ This can be done by using `openshift-install create install-config` first and ad
35
34
36
35
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).
37
36
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.
38
-
These virtual machines are *NOT* available in all regions. Users will also need to up the specific limits for `Standard_DC2as_v5` virtual machines.
37
+
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.
38
+
39
+
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.
39
40
40
41
image::coco-pattern/peer_pods.png[Schematic diagram of peer pods vs standard kata containers]
41
42
42
-
DNS for the openshift cluster also *MUST* be provided by azure DNS.
43
+
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.
43
44
44
45
== Azure configuration required for the validated pattern
45
46
46
-
The validated pattern requires access to azure apis to provision peer-pod VMs and to obtain certificates from let's encrypt.
47
+
The validated pattern requires access to Azure APIs to provision peer-pod VMs.
47
48
48
49
Azure configuration information must be provided in two places:
49
50
50
-
- The a secret must be loaded using a ../../../learn/secrets-management-in-the-validated-patterns-framework/[values-secret] file.
51
-
The https://github.com/validatedpatterns/coco-pattern/blob/main/values-secret.yaml.template[`values-secret.yaml.template`] file provides the appropriate structure
51
+
- A secret must be loaded using a ../../../learn/secrets-management-in-the-validated-patterns-framework/[values-secret] file.
52
+
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.
52
53
53
-
- 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).
54
+
- 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.
54
55
55
56
56
57
[source,yaml]
57
58
----
58
59
global:
59
60
azure:
60
-
clientID: '' # Service principle ID
61
+
clientID: '' # Service principal ID
61
62
subscriptionID: ''
62
63
tenantID: '' # Tenant ID
63
64
DNSResGroup: '' # Resource group for the azure DNS hosted zone
@@ -68,3 +69,4 @@ global:
68
69
clusterRegion: ''
69
70
----
70
71
72
+
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.
0 commit comments