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: add bare metal support for Intel TDX and AMD SEV-SNP
Adds a new `baremetal` clusterGroup with:
- NFD-based auto-detection of TDX/SEV-SNP hardware
- RuntimeClass for kata-tdx and kata-snp
- MachineConfig for kernel params and vsock
- Intel DCAP chart (PCCS + QGS) for TDX attestation
- LVMS and HPP storage provider support
- PCCS secrets generation in gen-secrets.sh
- Bare metal documentation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+38-9Lines changed: 38 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,21 +2,23 @@
2
2
3
3
Validated pattern for deploying confidential containers on OpenShift using the [Validated Patterns](https://validatedpatterns.io/) framework.
4
4
5
-
Confidential containers use hardware-backed Trusted Execution Environments (TEEs) to isolate workloads from cluster and hypervisor administrators. This pattern deploys and configures the Red Hat CoCo stack — including the sandboxed containers operator, Trustee (Key Broker Service), and peer-pod infrastructure — on Azure.
5
+
Confidential containers use hardware-backed Trusted Execution Environments (TEEs) to isolate workloads from cluster and hypervisor administrators. This pattern deploys and configures the Red Hat CoCo stack — including the sandboxed containers operator, Trustee (Key Broker Service), and peer-pod infrastructure — on Azure and bare metal.
6
6
7
7
## Topologies
8
8
9
-
The pattern provides two deployment topologies:
9
+
The pattern provides three deployment topologies:
10
10
11
-
1.**Single cluster** (`simple` clusterGroup) — deploys all components (Trustee, Vault, ACM, sandboxed containers, workloads) in one cluster. This breaks the RACI separation expected in a remote attestation architecture but simplifies testing and demonstrations.
11
+
1.**Single cluster** (`simple` clusterGroup) — deploys all components (Trustee, Vault, ACM, sandboxed containers, workloads) in one cluster on Azure. This breaks the RACI separation expected in a remote attestation architecture but simplifies testing and demonstrations.
12
12
13
13
2.**Multi-cluster** (`trusted-hub` + `spoke` clusterGroups) — separates the trusted zone from the untrusted workload zone:
14
14
-**Hub** (`trusted-hub`): Runs Trustee (KBS + attestation service), HashiCorp Vault, ACM, and cert-manager. This cluster is the trust anchor.
15
15
-**Spoke** (`spoke`): Runs the sandboxed containers operator and confidential workloads. The spoke is imported into ACM and managed from the hub.
16
16
17
+
3.**Bare metal** (`baremetal` clusterGroup) — deploys all components on bare metal hardware with Intel TDX or AMD SEV-SNP support. NFD (Node Feature Discovery) auto-detects the CPU architecture and configures the appropriate runtime. Supports SNO (Single Node OpenShift) and multi-node clusters.
18
+
17
19
The topology is controlled by the `main.clusterGroupName` field in `values-global.yaml`.
18
20
19
-
Currently supports Azure via peer-pods. Peer-pods provision confidential VMs (`Standard_DCas_v5` family) directly on the Azure hypervisor rather than nesting VMs inside worker nodes.
21
+
Azure deployments use peer-pods, which provision confidential VMs (`Standard_DCas_v5` family) directly on the Azure hypervisor. Bare metal deployments use layered images and hardware TEE features directly.
20
22
21
23
## Current version (4.*)
22
24
@@ -42,9 +44,18 @@ All previous versions used pre-GA (Technology Preview) releases of Trustee:
42
44
43
45
### Prerequisites
44
46
47
+
**Azure deployments:**
45
48
- OpenShift 4.17+ cluster on Azure (self-managed via `openshift-install` or ARO)
46
49
- Azure `Standard_DCas_v5` VM quota in your target region (these are confidential computing VMs and are not available in all regions). See the note below for more details.
47
50
- Azure DNS hosting the cluster's DNS zone
51
+
52
+
**Bare metal deployments:**
53
+
- OpenShift 4.17+ cluster on bare metal with Intel TDX or AMD SEV-SNP hardware
54
+
- BIOS/firmware configured to enable TDX or SEV-SNP
55
+
- Available block devices for LVMS storage (auto-discovered)
56
+
- For Intel TDX: an Intel PCS API key from [api.portal.trustedservices.intel.com](https://api.portal.trustedservices.intel.com/)
57
+
58
+
**Common:**
48
59
- Tools on your workstation: `podman`, `yq`, `jq`, `skopeo`
49
60
- OpenShift pull secret saved at `~/pull-secret.json` (download from [console.redhat.com](https://console.redhat.com/openshift/downloads))
50
61
- Fork the repository — ArgoCD reconciles cluster state against your fork, so changes must be pushed to your remote
@@ -53,20 +64,20 @@ All previous versions used pre-GA (Technology Preview) releases of Trustee:
53
64
54
65
These scripts generate the cryptographic material and attestation measurements needed by Trustee and the peer-pod VMs. Run them once before your first deployment.
55
66
56
-
1.`bash scripts/gen-secrets.sh` — generates KBS key pairs, attestation policy seeds, and copies `values-secret.yaml.template` to `~/values-secret-coco-pattern.yaml`
57
-
2.`bash scripts/get-pcr.sh` — retrieves PCR measurements from the peer-pod VM image and stores them at `~/.coco-pattern/measurements.json` (requires `podman`, `skopeo`, and `~/pull-secret.json`)
58
-
3. Review and customise `~/values-secret-coco-pattern.yaml` — this file is loaded into Vault and provides secrets to the pattern
67
+
1.`bash scripts/gen-secrets.sh` — generates KBS key pairs, PCCS certificates/tokens (for bare metal), and copies `values-secret.yaml.template` to `~/values-secret-coco-pattern.yaml`
68
+
2.`bash scripts/get-pcr.sh` — retrieves PCR measurements from the peer-pod VM image and stores them at `~/.coco-pattern/measurements.json` (requires `podman`, `skopeo`, and `~/pull-secret.json`). **Not required for bare metal deployments.**
69
+
3. Review and customise `~/values-secret-coco-pattern.yaml` — this file is loaded into Vault and provides secrets to the pattern. For bare metal, uncomment the PCCS secrets section and provide your Intel PCS API key.
59
70
60
71
> **Note:**`gen-secrets.sh` will not overwrite existing secrets. Delete `~/.coco-pattern/` if you need to regenerate.
61
72
62
-
### Single cluster deployment
73
+
### Single cluster deployment (Azure)
63
74
64
75
1. Set `main.clusterGroupName: simple` in `values-global.yaml`
65
76
2. Ensure your Azure configuration is populated in `values-global.yaml` (see `global.azure.*` fields)
66
77
3.`./pattern.sh make install`
67
78
4. Wait for the cluster to reboot all nodes (the sandboxed containers operator triggers a MachineConfig update). Monitor progress in the ArgoCD UI.
68
79
69
-
### Multi-cluster deployment
80
+
### Multi-cluster deployment (Azure)
70
81
71
82
1. Set `main.clusterGroupName: trusted-hub` in `values-global.yaml`
72
83
2. Deploy the hub cluster: `./pattern.sh make install`
@@ -76,6 +87,24 @@ These scripts generate the cryptographic material and attestation measurements n
76
87
(see [importing a cluster](https://validatedpatterns.io/learn/importing-a-cluster/))
77
88
6. ACM will automatically deploy the `spoke` clusterGroup applications (sandboxed containers, workloads) to the imported cluster
78
89
90
+
### Bare metal deployment
91
+
92
+
1. Set `main.clusterGroupName: baremetal` in `values-global.yaml`
93
+
2. Run `bash scripts/gen-secrets.sh` to generate KBS keys and PCCS secrets
94
+
3. For Intel TDX: uncomment the PCCS secrets in `~/values-secret-coco-pattern.yaml` and provide your Intel PCS API key
95
+
4.`./pattern.sh make install`
96
+
5. Wait for the cluster to reboot nodes (MachineConfig updates for TDX kernel parameters and vsock)
97
+
98
+
The system auto-detects your hardware:
99
+
-**NFD** discovers Intel TDX or AMD SEV-SNP capabilities and labels nodes
100
+
-**LVMS** auto-discovers available block devices for storage
101
+
-**RuntimeClass**`kata-cc` is created automatically pointing to the correct handler (`kata-tdx` or `kata-snp`)
102
+
- Both `kata-tdx` and `kata-snp` RuntimeClasses are deployed; only the one matching your hardware has schedulable nodes
103
+
- MachineConfigs are deployed for both `master` and `worker` roles (safe on SNO where only master exists)
104
+
- PCCS and QGS services deploy unconditionally; DaemonSets only schedule on Intel nodes via NFD labels
105
+
106
+
Optional: pin PCCS to a specific node with `bash scripts/get-pccs-node.sh` and set `baremetal.pccs.nodeSelector` in the baremetal chart values.
107
+
79
108
## Sample applications
80
109
81
110
Two sample applications are deployed on the cluster running confidential workloads (the single cluster in `simple` mode, or the spoke in multi-cluster mode):
0 commit comments