docs: address PR #73 review comments and merge PR #75 documentation

This commit addresses all review comments from bpradipt and pawelpros on
PR #73, merges documentation from PR #75, and updates container images.

Documentation changes:
- README: Replace "peer-pod infrastructure" wording to clarify Azure vs bare metal
- README: Update OCP version requirements from 4.17+ to 4.19.28+ (OSC 1.12 requirement)
- README: Clarify PCR collection differs for Azure (get-pcr.sh) vs bare metal (manual)
- README: Distinguish Azure (kata-remote) from bare metal (kata-cc) runtime classes
- values-secret.yaml.template: Add missing kbsPrivateKey secret
- values-secret.yaml.template: Reorganize with clear section headers and improved docs
- gen-secrets.sh: Add prominent alert when values-secret file is created
- Merge docs/nfd-matchall-bug.md from PR #75 (NFD matchAll bug report)
- Merge docs/pcr-reference-values-bare-metal.md from PR #75 (PCR collection guide)

Code cleanup:
- Delete obsolete qgs-config-cm.yaml (QGS args now inline)
- Delete obsolete qgs-sgx-cm.yaml (QCNL config via downwardAPI)
- Remove commented-out detect-runtime-class reference in values-baremetal.yaml

Image updates:
- intel-dpo-sgx.yaml: Update intel-sgx-plugin to sha256:4ac8769c (v0.35.0)
- pccs-deployment.yaml: Update osc-pccs to sha256:edf57087 (v1.12)
- qgs-ds.yaml: Update osc-tdx-qgs to sha256:308d66da (v1.12)

Resolves review comments from:
- bpradipt: peer-pod wording, OCP versions, PCR clarification
- pawelpros: obsolete ConfigMaps, image digests, PCR requirements

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: butler54

README.md

@@ -2,7 +2,7 @@
 
 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 and bare metal.
+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
 
@@ -24,7 +24,7 @@ Azure deployments use peer-pods, which provision confidential VMs (`Standard_DCa
 
 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)
@@ -46,13 +46,13 @@ All previous versions used pre-GA (Technology Preview) releases of Trustee:
 
 **Azure deployments:**
 
-- OpenShift 4.17+ cluster on Azure (self-managed via `openshift-install` or ARO)
+- 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.17+ cluster on bare metal with Intel TDX or AMD SEV-SNP hardware
+- 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/)
@@ -68,7 +68,7 @@ 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, 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`). **Not required for bare metal deployments.**
+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.
@@ -85,7 +85,7 @@ These scripts generate the cryptographic material and attestation measurements n
 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
@@ -118,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.
 

charts/all/intel-dcap/templates/intel-dpo-sgx.yaml

@@ -3,7 +3,7 @@ kind: SgxDevicePlugin
 metadata:
   name: sgxdeviceplugin-sample
 spec:
-  image: registry.connect.redhat.com/intel/intel-sgx-plugin@sha256:f2c77521c6dae6b4db1896a5784ba8b06a5ebb2a01684184fc90143cfcca7bf4
+  image: registry.connect.redhat.com/intel/intel-sgx-plugin@sha256:4ac8769c4f0a82b3ea04cf1532f15e9935c71fe390ff5a9dc3ee57f970a65f0b
   enclaveLimit: 110
   provisionLimit: 110
   logLevel: 4

charts/all/intel-dcap/templates/pccs-deployment.yaml

@@ -37,7 +37,7 @@ spec:
             privileged: true  # Required for chcon to work on host files
       containers:
         - name: pccs
-          image: registry.redhat.io/openshift-sandboxed-containers/osc-pccs@sha256:de64fc7b13aaa7e466e825d62207f77e7c63a4f9da98663c3ab06abc45f2334d
+          image: registry.redhat.io/openshift-sandboxed-containers/osc-pccs@sha256:edf57087220516115512dc6687b96045cbc69472a3d6d381619f66beae032ad6
           envFrom:
             - secretRef:
                 name: pccs-secrets

charts/all/intel-dcap/templates/qgs-config-cm.yaml

@@ -22,7 +22,7 @@ spec:
       dnsPolicy: ClusterFirstWithHostNet
       initContainers:
         - name: platform-registration
-          image: registry.redhat.io/openshift-sandboxed-containers/osc-tdx-qgs@sha256:86b23461c4eea073f4535a777374a54e934c37ac8c96c6180030f92ebf970524
+          image: registry.redhat.io/openshift-sandboxed-containers/osc-tdx-qgs@sha256:308d66da94d3116cc16530a4a2cd60a995458f331e1cb3487c6ea3fdae60545b
           restartPolicy: Always
           command: [ '/usr/bin/dcap-registration-flow' ]
           env:
@@ -47,7 +47,7 @@ spec:
               mountPath: /sys/firmware/efi/efivars
       containers:
         - name: tdx-qgs
-          image: registry.redhat.io/openshift-sandboxed-containers/osc-tdx-qgs@sha256:86b23461c4eea073f4535a777374a54e934c37ac8c96c6180030f92ebf970524
+          image: registry.redhat.io/openshift-sandboxed-containers/osc-tdx-qgs@sha256:308d66da94d3116cc16530a4a2cd60a995458f331e1cb3487c6ea3fdae60545b
           args:
             - -p=4050
             - -n=4

charts/all/intel-dcap/templates/qgs-ds.yaml

@@ -0,0 +1,122 @@
+# Bug Report: NFD `matchAll` Field Silently Dropped, Causing False TEE Labels
+
+## Summary
+
+`matchAll` is not a valid field in the NFD `NodeFeatureRule.spec.rules[]` schema. The correct field for AND-logic matching is `matchFeatures` (top-level on each rule). When `matchAll` is used, the OpenShift NFD operator silently drops it during the `nfd.openshift.io/v1alpha1` to `nfd.k8s-sigs.io/v1alpha1` conversion, leaving rules with no match predicates. These empty rules match every node unconditionally, applying all TEE labels regardless of hardware.
+
+## Impact
+
+- Every node receives ALL TEE labels: `intel.feature.node.kubernetes.io/tdx`, `amd.feature.node.kubernetes.io/snp`, `ibm.feature.node.kubernetes.io/se`, and `intel.feature.node.kubernetes.io/sgx`
+- The OpenShift sandboxed containers operator fails with: **`"multiple TEE platforms detected; only one per cluster supported"`**
+- KataConfig cannot reconcile, so no kata runtime handler is installed
+- All confidential container pods fail with: `failed to find runtime handler kata-snp from runtime list`
+
+## Root Cause
+
+The NFD `Rule` schema supports two match fields:
+
+| Field | Behavior | Valid? |
+|-------|----------|--------|
+| `matchFeatures` | Top-level list of feature matchers; ALL must match (AND) | Yes |
+| `matchAny` | List of match groups; ANY must match (OR) | Yes |
+| `matchAll` | **Does not exist in the NFD API** | No |
+
+When the chart template uses `matchAll`:
+
+```yaml
+# BROKEN - matchAll is not a valid field
+- name: "amd.sev-snp"
+  labels:
+    amd.feature.node.kubernetes.io/snp: "true"
+  matchAll:
+    - matchFeatures:
+        - feature: cpu.security
+          matchExpressions:
+            sev.snp.enabled: { op: Exists }
+```
+
+The OpenShift NFD operator creates a shadow resource under `nfd.k8s-sigs.io/v1alpha1`. During this conversion, `matchAll` is an unrecognized field and is silently stripped. The resulting live resource has:
+
+```yaml
+# RESULT - no match conditions, matches every node
+- name: "amd.sev-snp"
+  labels:
+    amd.feature.node.kubernetes.io/snp: "true"
+  labelsTemplate: ""
+  varsTemplate: ""
+```
+
+## Evidence
+
+**Node:** `master-03` (Intel Xeon, model family 6, ID 207, vendor: Intel)
+
+**NFD-reported hardware features (`cpu.security`):**
+
+```bash
+sgx.enabled: "true"
+sgx.epc: "4257210368"
+```
+
+Note: `sev.snp.enabled`, `tdx.enabled`, and `se.enabled` are **not present** in the node's feature data.
+
+**Labels applied to the node (all false positives except sgx):**
+
+```bash
+amd.feature.node.kubernetes.io/snp=true    # FALSE - Intel CPU, no SEV-SNP
+intel.feature.node.kubernetes.io/tdx=true  # FALSE - no tdx.enabled in cpu.security
+ibm.feature.node.kubernetes.io/se=true     # FALSE - Intel CPU, no SE
+intel.feature.node.kubernetes.io/sgx=true  # CORRECT - sgx.enabled is true
+feature.node.kubernetes.io/runtime.kata=true  # CORRECT - matchAny works (valid field)
+```
+
+**Sandbox operator log:**
+
+```text
+INFO  controllers.KataConfig  failed to detect TEE platform
+      {"err": "multiple TEE platforms detected; only one per cluster supported"}
+```
+
+## Fix
+
+Replace `matchAll` with `matchFeatures` in each rule. The `matchFeatures` list at the rule level uses AND logic (all entries must match), which is the intended behavior.
+
+Additionally, add vendor-discriminating CPUID checks to prevent cross-platform false positives:
+
+```yaml
+# FIXED - uses matchFeatures (valid field) with vendor guard
+- name: "amd.sev-snp"
+  labels:
+    amd.feature.node.kubernetes.io/snp: "true"
+  matchFeatures:
+    - feature: cpu.cpuid
+      matchExpressions:
+        SVM: { op: Exists }           # AMD-only CPUID flag
+    - feature: cpu.security
+      matchExpressions:
+        sev.snp.enabled: { op: Exists }
+```
+
+| Rule | `matchAll` (broken) | `matchFeatures` (fixed) | Vendor guard added |
+|------|---------------------|-------------------------|--------------------|
+| `amd.sev-snp` | Dropped silently | AND: SVM + sev.snp.enabled | `SVM` (AMD) |
+| `intel.sgx` | Dropped silently | AND: SGX + SGXLC + sgx.enabled + X86_SGX | `SGX`, `SGXLC` (Intel) |
+| `intel.tdx` | Dropped silently | AND: VMX + tdx.enabled | `VMX` (Intel) |
+| `ibm.se.enabled` | Dropped silently | AND: se.enabled | None (s390x only) |
+
+## Affected Versions
+
+Any deployment using the consolidated `NodeFeatureRule` (`consolidated-hardware-features`) introduced in commit `57ec5f4`. The original separate NFD rule files (`amd-nfd-rules.yaml`, `intel-nfd-rules.yaml`) used `matchFeatures` correctly but the consolidation mistakenly introduced `matchAll`.
+
+## Remediation
+
+After deploying the corrected chart:
+
+```bash
+# Remove false labels so NFD can re-evaluate
+oc label node <node> amd.feature.node.kubernetes.io/snp- \
+  intel.feature.node.kubernetes.io/tdx- \
+  ibm.feature.node.kubernetes.io/se-
+
+# Restart sandbox operator to re-evaluate KataConfig
+oc delete pod -n openshift-sandboxed-containers-operator -l app=controller-manager
+```