validatedpatterns · butler54 · Aug 31, 2026 · Aug 31, 2026 · Aug 31, 2026 · Aug 31, 2026
diff --git a/Makefile b/Makefile
@@ -5,6 +5,10 @@
 include Makefile-common
 
 ##@ Key Management
+.PHONY: gen-secrets
+gen-secrets: ## Generate KBS keys, sealed-secrets signing key, and values-secret template
+	@scripts/gen-secrets.sh
+
 .PHONY: cache-keys
 cache-keys: ## Download Red Hat signing keys from official sources to ~/.coco-pattern/
 	@mkdir -p ~/.coco-pattern
@@ -99,6 +103,14 @@ dcap-offline-provision: ## Full DCAP offline provisioning workflow (collect coll
 	$(MAKE) collect-dcap-collateral
 	$(MAKE) load-secrets
 
+.PHONY: check-pck-expiry
+check-pck-expiry: ## Check expiry of PCK cache secrets and platform data (requires oc login)
+	@scripts/check-pck-expiry.sh
+
+.PHONY: check-collateral-expiry
+check-collateral-expiry: ## Check expiry of TDX DCAP collateral in trustee-operator-system (requires oc login)
+	@scripts/check-collateral-expiry.sh
+
 ##@ AMD SEV-SNP VCEK Provisioning
 
 .PHONY: snp-collect-vcek-urls
@@ -191,6 +203,16 @@ argocd-login: ## Extract ArgoCD credentials from cluster and log in with argocd
 	fi
 
 ##@ Hardware Detection
+.PHONY: get-pccs-node
+get-pccs-node: ## Detect a node with Intel TDX support for PCCS deployment (requires KUBECONFIG or oc login)
+	@NODE=$$(oc get nodes -l intel.feature.node.kubernetes.io/tdx=true \
+		-o jsonpath='{.items[0].metadata.name}' 2>/dev/null); \
+	if [ -z "$$NODE" ]; then \
+		echo "ERROR: No TDX-capable nodes found" >&2; \
+		exit 1; \
+	fi; \
+	echo "$$NODE"
+
 .PHONY: detect-hardware
 detect-hardware: ## Detect hardware profile from cluster nodes (requires KUBECONFIG or oc login)
 	@echo "Detecting hardware profile from cluster nodes..."

diff --git a/README.md b/README.md
@@ -96,8 +96,8 @@ For air-gapped bare metal environments, see [`airgap/DEPLOY-RUNBOOK.md`](airgap/
 
 These scripts generate the cryptographic material and attestation reference values needed by Trustee. Run them once before your first deployment.
 
-1. `bash scripts/gen-secrets.sh` — generates KBS key pairs, sealed-secrets signing keys, and copies `values-secret.yaml.template` to `~/values-secret-coco-pattern.yaml`
-2. Collect attestation reference values (requires `podman`, `yq`, `jq`, and `~/pull-secret.json`):
+1. `make gen-secrets` — generates KBS key pairs, sealed-secrets signing keys, and copies `values-secret.yaml.template` to `~/values-secret-coco-pattern.yaml`
+2. Collect attestation reference values (requires `veritas` — `pip install "osc-veritas[snp]==0.1.3rc1"` —, `cosign` >= 2.0 for Azure, `yq`, `jq`, and `~/pull-secret.json`). By default this collects and merges reference values for **both TDX and SNP**:
    - **Azure:** `make collect-azure-refvals` — pulls PCR measurements from the dm-verity image via veritas. Saves to `~/.coco-pattern/measurements.json`.
    - **Bare metal:** `make collect-firmware-refvals` — computes firmware measurements from OCP release artifacts via veritas. Saves to `~/.coco-pattern/firmware-reference-values.json`. For bare metal, also uncomment the `firmwareReferenceValues` section in `~/values-secret-coco-pattern.yaml`.
    - See [docs/firmware-reference-values.md](docs/firmware-reference-values.md) for detailed workflow and options.

diff --git a/docs/firmware-reference-values.md b/docs/firmware-reference-values.md
@@ -13,14 +13,20 @@ Reference values are cryptographic measurements of the Trusted Computing Base (T
 | Bare metal | TDX | mr_td, rtmr_1, rtmr_2, xfam | SHA-384 |
 | Bare metal | SNP | snp_launch_measurement | SHA-384 |
 
-Both platforms use the [veritas](https://github.com/confidential-devhub/veritas) tool, packaged in the `quay.io/openshift_sandboxed_containers/coco-tools` container. No cluster access is required — veritas computes expected measurements from OCP release artifacts or the dm-verity image.
+Both platforms use the [veritas](https://github.com/confidential-devhub/veritas) tool. No cluster access is required — veritas computes expected measurements from OCP release artifacts or the dm-verity image.
+
+By default, `collect-firmware-refvals.sh` collects reference values for **both TDX and SNP and merges them** into a single output, so one RVPS ConfigMap supports heterogeneous (mixed-TEE) deployments out of the box — see [Multi-Architecture Collection](#multi-architecture-collection) below.
 
 ## Prerequisites
 
-- `podman` installed and running
+- `veritas` installed on the host: `pip install "osc-veritas[snp]==0.1.3rc1"`
+- `cosign` >= 2.0 — Azure only, used by veritas to verify the Red Hat dm-verity image signature: <https://docs.sigstore.dev/cosign/system_config/installation/>
 - `yq` and `jq` installed
 - OpenShift pull secret at `~/pull-secret.json`
 - For bare metal: OCP version of your cluster (auto-detected if `oc` is logged in)
+- For bare metal TDX: `tdx-measure` (`cargo install --git https://github.com/virtee/tdx-measure tdx-measure-cli`) — collection continues with a warning if absent, but TDX RTMR values will be incomplete
+
+**Why host-installed instead of the `coco-tools` container**: the container image (`quay.io/openshift_sandboxed_containers/coco-tools:0.5.1`) is pinned to an older veritas release that lacks `--skip-tlog`, which is needed to avoid the Azure verification failures described below. This is a deliberate, temporary deviation — see the tracking issue referenced in [Known Limitations](#known-limitations) for moving back to the container once a `coco-tools` release ships with a newer veritas.
 
 ## Collecting Reference Values
 
@@ -36,7 +42,9 @@ make collect-azure-refvals
 
 Output: `~/.coco-pattern/measurements.json`
 
-Veritas pulls the `osc-dm-verity-image` from the Red Hat registry, verifies its signature via cosign, and extracts pre-computed PCR values. These are the same values previously collected by `scripts/get-pcr.sh`.
+Veritas pulls the `osc-dm-verity-image` from the Red Hat registry, verifies its signature via cosign, and extracts pre-computed PCR values.
+
+**Signature verification and Rekor**: by default this script passes `--skip-tlog` to veritas for the Azure branch. Red Hat signs and logs these images against its own private Rekor instance, which has been unreliable (repeated `curl` failures fetching the Rekor public key). `--skip-tlog` still verifies the cosign signature against Red Hat's public key — it only skips the transparency-log lookup, which cannot succeed against a different Rekor server anyway (the log entry only exists on Red Hat's instance, so pointing at a different one, e.g. public Sigstore, does not work as a substitute). Pass `--verify-tlog` to opt back into full transparency-log verification if needed.
 
 ### Bare Metal
 
@@ -47,7 +55,7 @@ make collect-firmware-refvals
 # Or with explicit OCP version:
 ./scripts/collect-firmware-refvals.sh --ocp-version 4.20.18
 
-# Specify TEE type (default: tdx):
+# Collect a single TEE only (default is both, see below):
 ./scripts/collect-firmware-refvals.sh --tee snp --ocp-version 4.20.18
 ```
 
@@ -66,9 +74,18 @@ Options:
   -p, --pull-secret <path> Pull secret file (default: ~/pull-secret.json)
   -v, --ocp-version <ver>  OCP version (baremetal; default: auto-detect)
   --osc-version <ver>      OSC operator version (azure; default: auto-detect)
-  -t, --tee <tdx|snp>      TEE type (default: tdx)
+  -t, --tee <tdx|snp|both> TEE type (default: both -- collects and merges both)
+  --verify-tlog            Azure only: verify against Rekor instead of --skip-tlog
 ```
 
+## Multi-Architecture Collection
+
+By default (`--tee both`, or by omitting `--tee` entirely), this script runs veritas **twice** — once per TEE — and merges the resulting reference values into a single output file, for both the Azure and bare-metal branches. This supports heterogeneous/mixed-TEE deployments (for example, a bare-metal hub that verifies evidence from both TDX and SNP spokes, per `values-baremetal-hub.yaml`'s `kbs.tdx.enabled` + `kbs.snp.enabled`) without any manual merge step.
+
+The merge is a plain JSON key union: TDX and SNP reference values use disjoint, TEE-prefixed key names (`tdx_*`/`mr_td`/`rtmr_*` vs `snp_*`/`snp_launch_measurement`), so there's no collision risk, and this matches how `trustee-chart`'s RVPS template already consumes the `firmwareReferenceValues`/`pcrStash` secrets (it passes through whichever TEE-specific keys are present).
+
+Pass `--tee tdx` or `--tee snp` explicitly to collect a single architecture only (faster, useful for single-cluster deployments pinned to one hardware profile).
+
 ## Loading Values to Vault
 
 ### Step 1: Configure values-secret.yaml
@@ -149,13 +166,22 @@ The following table maps what veritas provides vs what the attestation policy ch
 | TEE type | Policy hardcoded | - | Policy hardcoded | - |
 | Init data | Computed by imperative job | Computed by imperative job | Computed by imperative job | Computed by imperative job |
 
-## Known Limitations
+## Azure "External" Reference Values (kbs.azure.*)
+
+Azure SEV-SNP also has a second, separate set of reference values that veritas does **not** collect: `trustee-chart`'s `kbs.azure.*` block (`snpLaunchMeasurement`, `smtEnabled`, `tsmeEnabled`, `abiMajor`, `abiMinor`, `singleSocket`, `smtAllowed`). These are static Azure-platform/VM-series constants (describing the SEV-SNP policy Azure enforces for a given confidential VM series), not measurements derived from any artifact veritas can pull and hash.
+
+coco-pattern pins these explicitly in `overrides/values-trustee-azure.yaml` (wired into `values-azure.yaml`) rather than silently relying on `trustee-chart`'s own defaults, so the values are visible/versioned in this repository. See that file's comments for the current VM-series mapping and for how to update them if you change `global.azure.defaultVMFlavour` to a series with different platform behavior.
 
-As of the coco-tools 1.12 container:
+**Note**: as of the current `trustee-chart` attestation policy, the Rego checks that would compare evidence against these values are commented out upstream ("Azure manages TCB validation"), so they are not currently enforced — they're pinned here so they're ready to take effect if/when upstream re-enables those checks, and so the values are documented and auditable rather than hidden inside a dependency chart's defaults.
+
+There is currently no automated way to collect/verify these values against a real deployment. A `snpguest`-based collection script (SSH into the podvm with `enableSSHDebug`, run `snpguest report --openhcl`, parse the SNP attestation report) is tracked as a follow-up.
+
+## Known Limitations
 
 1. **TCB version numbers** — Not collected for SNP (reported_tcb_bootloader, tcb_microcode, etc.). Hardware trust claim fallback rules handle this.
-2. **SNP policy configuration** — SMT, TSME, guest ABI not output. Configuration fallback rules check debug disabled + init_data.
+2. **Azure SNP platform configuration** — SMT, TSME, guest ABI are not collected by veritas at all (see [Azure "External" Reference Values](#azure-external-reference-values-kbsazure) above); bare-metal SNP configuration fallback rules check debug disabled + init_data instead.
 3. **rtmr_2 variants** — Veritas generates multiple cmdline variants (nr_cpus=1..N). If the actual cmdline differs, the policy falls back to the rtmr_1-only rule (executables: 4 instead of 3).
+4. **Host-installed veritas instead of the `coco-tools` container** — temporary, until `coco-tools` publishes a release pinning a newer veritas with `--skip-tlog`/`--cosign-pub-key`/`--mirror-registry` support. See the tracking issue for details and for moving back to the container-based approach.
 
 ## Security Considerations
 

diff --git a/overrides/values-trustee-azure.yaml b/overrides/values-trustee-azure.yaml
@@ -0,0 +1,45 @@
+# Azure SEV-SNP platform configuration reference values, pinned explicitly in
+# coco-pattern rather than silently inherited from trustee-chart's own
+# values.yaml defaults.
+#
+# These describe the SEV-SNP policy Azure enforces for confidential VMs of a
+# given series. They are NOT derived from the workload image -- they are
+# Azure platform constants for the VM type -- and are NOT collected by
+# 'make collect-azure-refvals' (veritas does not compute these; see
+# docs/firmware-reference-values.md "Known Limitations").
+#
+# Current values below match Azure DCasv5-series VMs (this pattern's default
+# VM flavour, see global.azure.defaultVMFlavour in values-global.yaml):
+#
+#   VM Series       | SMT | TSME | ABI Minor | Notes
+#   ----------------|-----|------|-----------|------
+#   DCasv5 (Genoa)  | true| true | 31        | Standard CoCo peer-pod VMs (default)
+#   DCadsv5 (Genoa) | true| true | 31        | With local NVMe
+#   ECasv5 (Genoa)  | true| true | 31        | Memory-optimized
+#   DCesv5 (Milan)  | true| true | 31        | Earlier generation, may differ
+#
+# If you change global.azure.defaultVMFlavour to a series with different
+# platform behaviour, or if Azure updates its confidential VM firmware,
+# update the values below to match. There is currently no automated way to
+# collect them (see the tracking issue for a snpguest-based collection
+# script) -- the only documented method today is: check the trustee logs
+# (RUST_LOG=debug is enabled by default on the KBS pod) for the actual
+# values reported by the VM on attestation failure, and update these to
+# match.
+#
+# NOTE: as of trustee-chart's current attestation-policy.yaml, the Rego
+# checks that would compare evidence against these values (smt_enabled,
+# tsme_enabled, abi_major/minor, single_socket, smt_allowed) are commented
+# out upstream ("Azure manages TCB validation" / "Azure platform
+# constants"), so these are not currently enforced. They are pinned here
+# so the values are visible/versioned in this repo, and ready to take
+# effect if/when upstream re-enables those policy checks.
+kbs:
+  azure:
+    snpLaunchMeasurement: "qnydpVwThuWxZTsSWXi+2ns/laha6w+d2723g84FaijJ0CHaI5w0pYw6ZXZUJw7v"
+    smtEnabled: "true"
+    tsmeEnabled: "true"
+    abiMajor: "0"
+    abiMinor: "31"
+    singleSocket: "false"
+    smtAllowed: "true"
diff --git a/rhdp/README.md b/rhdp/README.md
@@ -5,7 +5,9 @@ The scripts in this directory help users of that platform automate deployments.
 
 ## Prerequisites
 
-- `podman` installed and running (used for reference value collection)
+- `podman` installed and running (used by `pattern.sh` itself)
+- `veritas` installed on the host (used for reference value collection): `pip install "osc-veritas[snp]==0.1.3rc1"`
+- `cosign` >= 2.0 (used by veritas for Azure image signature verification)
 - `yq`, `jq` installed
 - OpenShift pull secret (default: `~/pull-secret.json`, override with `PULL_SECRET` — see below)
 - An SSH key pair (default: auto-detected, preferring Ed25519 — override with `SSH_PUBLIC_KEY` — see below)