validatedpatterns
diff --git a/‎README.md‎
Lines changed: 46 additions & 13 deletions b/‎README.md‎
Lines changed: 46 additions & 13 deletions
diff --git a/‎ansible/init-data-gzipper.yaml‎
Lines changed: 18 additions & 4 deletions b/‎ansible/init-data-gzipper.yaml‎
Lines changed: 18 additions & 4 deletions
diff --git a/‎charts/all/baremetal/Chart.yaml‎
Lines changed: 9 additions & 0 deletions b/‎charts/all/baremetal/Chart.yaml‎
Lines changed: 9 additions & 0 deletions
diff --git a/‎charts/all/baremetal/templates/kata-nfd.yaml‎
Lines changed: 80 additions & 0 deletions b/‎charts/all/baremetal/templates/kata-nfd.yaml‎
Lines changed: 80 additions & 0 deletions
diff --git a/‎charts/all/baremetal/templates/nfd-instance.yaml‎
Lines changed: 12 additions & 0 deletions b/‎charts/all/baremetal/templates/nfd-instance.yaml‎
Lines changed: 12 additions & 0 deletions
diff --git a/‎charts/all/baremetal/templates/vsock-mco.yaml‎
Lines changed: 24 additions & 0 deletions b/‎charts/all/baremetal/templates/vsock-mco.yaml‎
Lines changed: 24 additions & 0 deletions
diff --git a/‎charts/all/baremetal/values.yaml‎
Lines changed: 2 additions & 0 deletions b/‎charts/all/baremetal/values.yaml‎
Lines changed: 2 additions & 0 deletions
diff --git a/‎charts/all/coco-kyverno-policies/templates/inject-coco-initdata.yaml‎
Lines changed: 4 additions & 4 deletions b/‎charts/all/coco-kyverno-policies/templates/inject-coco-initdata.yaml‎
Lines changed: 4 additions & 4 deletions
diff --git a/‎charts/all/intel-dcap/Chart.yaml‎
Lines changed: 10 additions & 0 deletions b/‎charts/all/intel-dcap/Chart.yaml‎
Lines changed: 10 additions & 0 deletions
diff --git a/‎charts/all/intel-dcap/templates/intel-dpo-sgx.yaml‎
Lines changed: 11 additions & 0 deletions b/‎charts/all/intel-dcap/templates/intel-dpo-sgx.yaml‎
Lines changed: 11 additions & 0 deletions
@@ -2,27 +2,29 @@
 
 Validated pattern for deploying confidential containers on OpenShift using the [Validated Patterns](https://validatedpatterns.io/) framework.
 
-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.
+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) operator, and Kata infrastructure — on Azure cloud instances and bare metal.
 
 ## Topologies
 
-The pattern provides two deployment topologies:
+The pattern provides three deployment topologies:
 
-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.
+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.
 
 2. **Multi-cluster** (`trusted-hub` + `spoke` clusterGroups) — separates the trusted zone from the untrusted workload zone:
    - **Hub** (`trusted-hub`): Runs Trustee (KBS + attestation service), HashiCorp Vault, ACM, and cert-manager. This cluster is the trust anchor.
    - **Spoke** (`spoke`): Runs the sandboxed containers operator and confidential workloads. The spoke is imported into ACM and managed from the hub.
 
+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.
+
 The topology is controlled by the `main.clusterGroupName` field in `values-global.yaml`.
 
-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.
+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.
 
 ## Current version (4.*)
 
 Breaking change from v3. This is the first version using GA (Generally Available) releases of the CoCo stack:
 
-- **OpenShift Sandboxed Containers 1.12+** (requires OCP 4.17+)
+- **OpenShift Sandboxed Containers 1.12+** (requires OCP 4.19.28+)
 - **Red Hat Build of Trustee 1.1** (GA release; all versions prior to 1.0 were Technology Preview)
 - External chart repositories for [Trustee](https://github.com/validatedpatterns/trustee-chart), [sandboxed-containers](https://github.com/validatedpatterns/sandboxed-containers-chart), and [sandboxed-policies](https://github.com/validatedpatterns/sandboxed-policies-chart)
 - Self-signed certificates via cert-manager (Let's Encrypt no longer required)
@@ -42,9 +44,21 @@ All previous versions used pre-GA (Technology Preview) releases of Trustee:
 
 ### Prerequisites
 
-- OpenShift 4.17+ cluster on Azure (self-managed via `openshift-install` or ARO)
+**Azure deployments:**
+
+- OpenShift 4.19.28+ cluster on Azure (self-managed via `openshift-install` or ARO)
 - 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.
 - Azure DNS hosting the cluster's DNS zone
+
+**Bare metal deployments:**
+
+- OpenShift 4.19.28+ cluster on bare metal with Intel TDX or AMD SEV-SNP hardware
+- BIOS/firmware configured to enable TDX or SEV-SNP
+- Available block devices for LVMS storage (auto-discovered)
+- For Intel TDX: an Intel PCS API key from [api.portal.trustedservices.intel.com](https://api.portal.trustedservices.intel.com/)
+
+**Common:**
+
 - Tools on your workstation: `podman`, `yq`, `jq`, `skopeo`
 - OpenShift pull secret saved at `~/pull-secret.json` (download from [console.redhat.com](https://console.redhat.com/openshift/downloads))
 - Fork the repository — ArgoCD reconciles cluster state against your fork, so changes must be pushed to your remote
@@ -53,29 +67,48 @@ All previous versions used pre-GA (Technology Preview) releases of Trustee:
 
 These scripts generate the cryptographic material and attestation measurements needed by Trustee and the peer-pod VMs. Run them once before your first deployment.
 
-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`
-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`)
-3. Review and customise `~/values-secret-coco-pattern.yaml` — this file is loaded into Vault and provides secrets to the pattern
+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`
+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`). **Azure only.** Bare metal uses manual PCR collection — see [docs/pcr-reference-values-bare-metal.md](docs/pcr-reference-values-bare-metal.md) for the procedure. Store the measurements at `~/.coco-pattern/measurements.json`.
+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.
 
 > **Note:** `gen-secrets.sh` will not overwrite existing secrets. Delete `~/.coco-pattern/` if you need to regenerate.
 
-### Single cluster deployment
+### Single cluster deployment (Azure)
 
 1. Set `main.clusterGroupName: simple` in `values-global.yaml`
 2. Ensure your Azure configuration is populated in `values-global.yaml` (see `global.azure.*` fields)
 3. `./pattern.sh make install`
 4. Wait for the cluster to reboot all nodes (the sandboxed containers operator triggers a MachineConfig update). Monitor progress in the ArgoCD UI.
 
-### Multi-cluster deployment
+### Multi-cluster deployment (Azure)
 
 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
-4. Provision a second OpenShift 4.17+ cluster on Azure for the spoke
+4. Provision a second OpenShift 4.19.28+ cluster on Azure for the spoke
 5. Import the spoke into ACM with label `clusterGroup=spoke`
    (see [importing a cluster](https://validatedpatterns.io/learn/importing-a-cluster/))
 6. ACM will automatically deploy the `spoke` clusterGroup applications (sandboxed containers, workloads) to the imported cluster
 
+### Bare metal deployment
+
+1. Set `main.clusterGroupName: baremetal` in `values-global.yaml`
+2. Run `bash scripts/gen-secrets.sh` to generate KBS keys and PCCS secrets
+3. For Intel TDX: uncomment the PCCS secrets in `~/values-secret-coco-pattern.yaml` and provide your Intel PCS API key
+4. `./pattern.sh make install`
+5. Wait for the cluster to reboot nodes (MachineConfig updates for TDX kernel parameters and vsock)
+
+The system auto-detects your hardware:
+
+- **NFD** discovers Intel TDX or AMD SEV-SNP capabilities and labels nodes
+- **LVMS** auto-discovers available block devices for storage
+- **RuntimeClass** `kata-cc` is created automatically pointing to the correct handler (`kata-tdx` or `kata-snp`)
+- Both `kata-tdx` and `kata-snp` RuntimeClasses are deployed; only the one matching your hardware has schedulable nodes
+- MachineConfigs are deployed for both `master` and `worker` roles (safe on SNO where only master exists)
+- PCCS and QGS services deploy unconditionally; DaemonSets only schedule on Intel nodes via NFD labels
+
+Optional: pin PCCS to a specific node with `bash scripts/get-pccs-node.sh` and set `baremetal.pccs.nodeSelector` in the baremetal chart values.
+
 ## Sample applications
 
 Two sample applications are deployed on the cluster running confidential workloads (the single cluster in `simple` mode, or the spoke in multi-cluster mode):
@@ -85,7 +118,7 @@ Two sample applications are deployed on the cluster running confidential workloa
   - `secure` — a confidential container with a strict policy; `oc exec` is denied even for `kubeadmin`
   - `insecure-policy` — a confidential container with a relaxed policy allowing `oc exec` (useful for testing the Confidential Data Hub)
 
-  Each confidential pod runs on its own `Standard_DC2as_v5` Azure VM (visible in the Azure portal). Pods use `runtimeClassName: kata-remote`.
+  On Azure, each confidential pod runs on its own `Standard_DC2as_v5` Azure VM (visible in the Azure portal) using `runtimeClassName: kata-remote`. On bare metal, pods use `runtimeClassName: kata-cc` and run directly on the underlying TDX or SEV-SNP hardware.
 
 - **kbs-access**: A web service that retrieves and presents secrets obtained from the Trustee Key Broker Service (KBS) via the Confidential Data Hub (CDH). Useful for verifying end-to-end attestation and secret delivery in locked-down environments.
 
 
@@ -114,21 +114,33 @@
       register: debug_initdata_encoded
       changed_when: false
 
+    - name: Compute raw SHA-256 hash of default initdata
+      ansible.builtin.shell: |
+        set -o pipefail
+        sha256sum "{{ rendered_path }}" | cut -d' ' -f1
+      register: raw_hash
+      changed_when: false
+
+    - name: Compute raw SHA-256 hash of debug initdata
+      ansible.builtin.shell: |
+        set -o pipefail
+        sha256sum "{{ debug_rendered_path }}" | cut -d' ' -f1
+      register: debug_raw_hash
+      changed_when: false
+
     - name: Register init data pcr into a var
       ansible.builtin.shell: |
         set -o pipefail
-        hash=$(sha256sum "{{ rendered_path }}" | cut -d' ' -f1)
         initial_pcr=0000000000000000000000000000000000000000000000000000000000000000
-        PCR8_HASH=$(echo -n "$initial_pcr$hash" | xxd -r -p | sha256sum | cut -d' ' -f1) && echo $PCR8_HASH
+        PCR8_HASH=$(echo -n "${initial_pcr}{{ raw_hash.stdout }}" | xxd -r -p | sha256sum | cut -d' ' -f1) && echo $PCR8_HASH
       register: pcr8_hash
       changed_when: false
 
     - name: Register debug init data pcr into a var
       ansible.builtin.shell: |
         set -o pipefail
-        hash=$(sha256sum "{{ debug_rendered_path }}" | cut -d' ' -f1)
         initial_pcr=0000000000000000000000000000000000000000000000000000000000000000
-        PCR8_HASH=$(echo -n "$initial_pcr$hash" | xxd -r -p | sha256sum | cut -d' ' -f1) && echo $PCR8_HASH
+        PCR8_HASH=$(echo -n "${initial_pcr}{{ debug_raw_hash.stdout }}" | xxd -r -p | sha256sum | cut -d' ' -f1) && echo $PCR8_HASH
       register: debug_pcr8_hash
       changed_when: false
 
@@ -147,6 +159,7 @@
           data:
             INITDATA: "{{ initdata_encoded.stdout }}"
             PCR8_HASH: "{{ pcr8_hash.stdout }}"
+            RAW_HASH: "{{ raw_hash.stdout }}"
             version: "0.1.0"
             algorithm: "sha256"
             aa.toml: "{{ raw_aa_toml.stdout }}"
@@ -168,6 +181,7 @@
           data:
             INITDATA: "{{ debug_initdata_encoded.stdout }}"
             PCR8_HASH: "{{ debug_pcr8_hash.stdout }}"
+            RAW_HASH: "{{ debug_raw_hash.stdout }}"
             version: "0.1.0"
             algorithm: "sha256"
             aa.toml: "{{ raw_aa_toml.stdout }}"
 
@@ -0,0 +1,9 @@
+apiVersion: v2
+description: Bare metal platform configuration (NFD rules, MachineConfigs, RuntimeClasses, Intel device plugin).
+keywords:
+- pattern
+- upstream
+- sandbox
+- baremetal
+name: baremetal
+version: 0.0.1
@@ -0,0 +1,80 @@
+apiVersion: nfd.openshift.io/v1alpha1
+kind: NodeFeatureRule
+metadata:
+  name: consolidated-hardware-features
+  namespace: openshift-nfd
+spec:
+  rules:
+    - name: "runtime.kata"
+      labels:
+        feature.node.kubernetes.io/runtime.kata: "true"
+      matchAny:
+        - matchFeatures:
+            - feature: cpu.cpuid
+              matchExpressions:
+                SSE42: { op: Exists }
+                VMX: { op: Exists }
+            - feature: kernel.loadedmodule
+              matchExpressions:
+                kvm: { op: Exists }
+                kvm_intel: { op: Exists }
+        - matchFeatures:
+            - feature: cpu.cpuid
+              matchExpressions:
+                SSE42: { op: Exists }
+                SVM: { op: Exists }
+            - feature: kernel.loadedmodule
+              matchExpressions:
+                kvm: { op: Exists }
+                kvm_amd: { op: Exists }
+
+    - name: "amd.sev-snp"
+      labels:
+        amd.feature.node.kubernetes.io/snp: "true"
+      extendedResources:
+        sev-snp.amd.com/esids: "@cpu.security.sev.encrypted_state_ids"
+      matchFeatures:
+        - feature: cpu.cpuid
+          matchExpressions:
+            SVM: { op: Exists }
+        - feature: cpu.security
+          matchExpressions:
+            sev.snp.enabled: { op: Exists }
+
+    - name: "intel.sgx"
+      labels:
+        intel.feature.node.kubernetes.io/sgx: "true"
+      extendedResources:
+        sgx.intel.com/epc: "@cpu.security.sgx.epc"
+      matchFeatures:
+        - feature: cpu.cpuid
+          matchExpressions:
+            SGX: { op: Exists }
+            SGXLC: { op: Exists }
+        - feature: cpu.security
+          matchExpressions:
+            sgx.enabled: { op: IsTrue }
+        - feature: kernel.config
+          matchExpressions:
+            X86_SGX: { op: Exists }
+
+    - name: "intel.tdx"
+      labels:
+        intel.feature.node.kubernetes.io/tdx: "true"
+      extendedResources:
+        tdx.intel.com/keys: "@cpu.security.tdx.total_keys"
+      matchFeatures:
+        - feature: cpu.cpuid
+          matchExpressions:
+            VMX: { op: Exists }
+        - feature: cpu.security
+          matchExpressions:
+            tdx.enabled: { op: Exists }
+
+    - name: "ibm.se.enabled"
+      labels:
+        ibm.feature.node.kubernetes.io/se: "true"
+      matchFeatures:
+        - feature: cpu.security
+          matchExpressions:
+            se.enabled: { op: IsTrue }
@@ -0,0 +1,12 @@
+apiVersion: nfd.openshift.io/v1
+kind: NodeFeatureDiscovery
+metadata:
+  name: nfd-instance
+  namespace: openshift-nfd
+spec:
+  operand:
+    image: registry.redhat.io/openshift4/ose-node-feature-discovery-rhel9:v4.20
+    imagePullPolicy: Always
+    servicePort: 12000
+  workerConfig:
+    configData: |
@@ -0,0 +1,24 @@
+{{- range list "master" "worker" }}
+---
+apiVersion: machineconfiguration.openshift.io/v1
+kind: MachineConfig
+metadata:
+  labels:
+    machineconfiguration.openshift.io/role: {{ . }}
+  name: 99-enable-coco-{{ . }}
+spec:
+  kernelArguments:
+  - nohibernate
+{{- if $.Values.tdx.enabled }}
+  - kvm_intel.tdx=1
+{{- end }}
+  config:
+    ignition:
+      version: 3.2.0
+    storage:
+      files:
+        - path: /etc/modules-load.d/vsock.conf
+          mode: 0644
+          contents:
+            source: data:text/plain;charset=utf-8;base64,dnNvY2stbG9vcGJhY2sK
+{{- end }}
@@ -0,0 +1,2 @@
+tdx:
+  enabled: true
@@ -6,14 +6,14 @@ metadata:
     policies.kyverno.io/title: Inject CoCo InitData
     policies.kyverno.io/category: Confidential Computing
     policies.kyverno.io/severity: medium
-    policies.kyverno.io/subject: Pod,Deployment
+    policies.kyverno.io/subject: Pod
     policies.kyverno.io/description: >-
       Injects cc_init_data annotation into pods with a kata runtime class
       by reading from a ConfigMap specified via the coco.io/initdata-configmap
-      annotation. Kyverno autogen extends this to Deployments, StatefulSets,
-      DaemonSets, and Jobs automatically.
+      annotation. Targets Pods only (not Deployments) so that Deployments
+      remain stable and a rollout restart resolves the latest initdata.
     argocd.argoproj.io/sync-wave: "1"
-    pod-policies.kyverno.io/autogen-controllers: Deployment,StatefulSet,DaemonSet,Job
+    pod-policies.kyverno.io/autogen-controllers: none
 spec:
   rules:
     - name: inject-initdata
 
@@ -0,0 +1,10 @@
+apiVersion: v2
+description: Intel DCAP services (PCCS and QGS) for TDX remote attestation.
+keywords:
+- pattern
+- intel
+- tdx
+- pccs
+- qgs
+name: intel-dcap
+version: 0.0.1
@@ -0,0 +1,11 @@
+apiVersion: deviceplugin.intel.com/v1
+kind: SgxDevicePlugin
+metadata:
+  name: sgxdeviceplugin-sample
+spec:
+  image: registry.connect.redhat.com/intel/intel-sgx-plugin@sha256:4ac8769c4f0a82b3ea04cf1532f15e9935c71fe390ff5a9dc3ee57f970a65f0b
+  enclaveLimit: 110
+  provisionLimit: 110
+  logLevel: 4
+  nodeSelector:
+    intel.feature.node.kubernetes.io/sgx: "true"