From aafe426f699ff11385296a292839ff836e6122d5 Mon Sep 17 00:00:00 2001 From: Chris Butler Date: Tue, 2 Jun 2026 13:20:49 +0800 Subject: [PATCH 1/2] docs: update documentation and bump sandboxed-policies to 0.2.* Documentation updates: - Rewrite docs/firmware-reference-values.md for container-based veritas approach covering both Azure and bare metal platforms - Update README.md secrets section: replace get-pcr.sh reference with unified collect-firmware-refvals.sh, add Azure and bare metal commands - Fix AGENTS.md: correct values-spoke.yaml filename, add baremetal-gpu cluster group, update companion chart table to reflect registry-based consumption instead of stale local paths Chart version bump: - Bump sandboxed-policies chartVersion from 0.1.* to 0.2.* in all four profiles (v0.2.0 adds Azure-conditional peer-pods policy) Co-Authored-By: Claude Opus 4.6 (1M context) --- AGENTS.md | 23 ++- README.md | 9 +- docs/firmware-reference-values.md | 333 +++++++++--------------------- values-baremetal-gpu.yaml | 2 +- values-baremetal.yaml | 2 +- values-simple.yaml | 2 +- values-trusted-hub.yaml | 2 +- 7 files changed, 115 insertions(+), 258 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index d88316da..b99090a0 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -17,7 +17,7 @@ This file provides rules and context for any AI coding assistant working in this Use the **first** approach that fits your requirement: 1. **Helm charts** — Declarative Kubernetes resources in `/charts/`, deployed by ArgoCD. Preferred for installing operators, configuring CRDs, and creating Kubernetes resources. -2. **ACM policies** — Red Hat Advanced Cluster Management policies for propagating configuration from hub to spoke clusters and enforcing multi-cluster governance. Reference: `charts/hub/sandbox-policies/templates/`. +2. **ACM policies** — Red Hat Advanced Cluster Management policies for propagating configuration from hub to spoke clusters and enforcing multi-cluster governance. Reference: `validatedpatterns/sandboxed-policies-chart`. 3. **Imperative framework (Ansible)** — Playbooks in `/ansible/`, executed as Kubernetes Jobs on a 10-minute schedule. **Must be idempotent.** Use for API calls, runtime data lookups, and multi-step orchestration that cannot be expressed declaratively. Register playbooks in `clusterGroup.imperative.jobs` as an ordered list. 4. **Out-of-band scripts** — `/scripts/` or `/rhdp/`. Last resort for one-time setup or local development tooling. These are not managed by GitOps. @@ -48,21 +48,21 @@ Use the **first** approach that fits your requirement: ├── values-simple.yaml # Cluster group: simple ├── values-baremetal.yaml # Cluster group: baremetal ├── values-trusted-hub.yaml # Cluster group: trusted-hub -├── values-untrusted-spoke.yaml # Cluster group: untrusted-spoke +├── values-spoke.yaml # Cluster group: spoke └── values-secret.yaml.template # Secrets template (never commit filled-in copy) ``` ## Companion Chart Repositories -Several charts in this repository have companion repositories for independent versioning and reuse. Develop and test in this repository first (charts deploy via `path:`), then sync changes to the companion repository. +These charts are published independently and consumed from the `charts.validatedpatterns.io` Helm registry via `chart:` + `chartVersion:` in the values files. -| Local Path | Companion Repository | Purpose | +| Chart Name | Repository | Purpose | |---|---|---| -| `charts/hub/trustee/` | `trustee-chart` | Trustee / KBS on hub | -| `charts/hub/sandbox-policies/` | `sandboxed-policies-chart` | ACM policies hub → spoke | -| `charts/coco-supported/sandbox/` | `sandboxed-containers-chart` | Sandboxed runtime on spoke | +| `trustee` | `validatedpatterns/trustee-chart` | Trustee / KBS configuration | +| `sandboxed-policies` | `validatedpatterns/sandboxed-policies-chart` | ACM policies hub → spoke | +| `sandboxed-containers` | `validatedpatterns/sandboxed-containers-chart` | Sandboxed runtime on spoke | -Large features may require coordinated changes across multiple companion repos. References are org-agnostic — contributors should fork all relevant repos as needed. +Changes to companion charts require a release (git tag) before the pattern can consume them. Update the `chartVersion:` field in the values files to pick up new releases. ## Cluster Groups @@ -70,10 +70,11 @@ Set via `main.clusterGroupName` in `values-global.yaml`. | Cluster Group | Values File | Role | Description | |---|---|---|---| -| `simple` | `values-simple.yaml` | Hub (single cluster) | All components on one cluster | -| `baremetal` | `values-baremetal.yaml` | Hub (single cluster) | TDX + LVM storage on bare metal | +| `simple` | `values-simple.yaml` | Hub (single cluster) | All components on one Azure cluster | +| `baremetal` | `values-baremetal.yaml` | Hub (single cluster) | TDX/SNP + LVM storage on bare metal | +| `baremetal-gpu` | `values-baremetal-gpu.yaml` | Hub (single cluster) | Bare metal + NVIDIA H100 GPU support | | `trusted-hub` | `values-trusted-hub.yaml` | Multi-cluster hub | Trustee + ACM policies | -| `untrusted-spoke` | `values-untrusted-spoke.yaml` | Multi-cluster spoke | Sandbox runtime + workloads | +| `spoke` | `values-spoke.yaml` | Multi-cluster spoke | Sandbox runtime + workloads | ## Values File Hierarchy diff --git a/README.md b/README.md index c52b8723..6151fbba 100644 --- a/README.md +++ b/README.md @@ -62,12 +62,15 @@ Breaking change from v4. Uses GA releases of the CoCo stack with Kyverno-based i - 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 -### Secrets and PCR setup +### Secrets and reference value setup -These scripts generate the cryptographic material and attestation measurements needed by Trustee and the peer-pod VMs. Run them once before your first deployment. +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, 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`. +2. Collect attestation reference values (requires `podman`, `yq`, `jq`, and `~/pull-secret.json`): + - **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. 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. diff --git a/docs/firmware-reference-values.md b/docs/firmware-reference-values.md index 4c9ccff6..efbbc936 100644 --- a/docs/firmware-reference-values.md +++ b/docs/firmware-reference-values.md @@ -1,87 +1,81 @@ -# Firmware Reference Values for Bare Metal Attestation +# Collecting Reference Values for Attestation -This guide explains how to collect firmware reference values for bare metal confidential computing deployments (Intel TDX / AMD SEV-SNP). +This guide explains how to collect firmware and PCR reference values for confidential computing deployments on both Azure and bare metal (Intel TDX / AMD SEV-SNP). ## Overview -Firmware reference values are cryptographic measurements of the Trusted Computing Base (TCB) components: +Reference values are cryptographic measurements of the Trusted Computing Base (TCB). The Trustee attestation service compares these against evidence from running workloads to verify integrity. -- **Intel TDX**: `mr_td` (OVMF code hash), `rtmr_1` (kernel/initrd), `rtmr_2` (cmdline), `xfam` (extended features) -- **AMD SEV-SNP**: `snp_launch_measurement` (firmware/kernel/initrd hash) +| Platform | TEE | Measurements | Hash Algorithm | +|----------|-----|-------------|----------------| +| Azure | TDX (vTPM) | PCR03, PCR09, PCR11, PCR12 | SHA-256 | +| Azure | SNP (vTPM) | PCR03, PCR09, PCR11, PCR12 | SHA-256 | +| Bare metal | TDX | mr_td, rtmr_1, rtmr_2, xfam | SHA-384 | +| Bare metal | SNP | snp_launch_measurement | SHA-384 | -These values are used by the KBS attestation policy to verify that confidential workloads are running on approved firmware with expected security properties. +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. ## Prerequisites -### 1. Veritas Tool +- `podman` installed and running +- `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) -The [veritas](https://github.com/confidential-containers/veritas) tool collects attestation evidence from confidential VMs. +## Collecting Reference Values -**Installation:** Veritas is automatically installed inside the collection pod by the script. No local installation required. +### Azure -**Version requirement**: 0.2.0 or later +```bash +# Collect PCR values from the dm-verity image +make collect-azure-refvals -### 2. Bare Metal Cluster Access +# Or with explicit OSC version: +./scripts/collect-firmware-refvals.sh --platform azure --osc-version 1.12.0 +``` -You need: +Output: `~/.coco-pattern/measurements.json` -- A running bare metal cluster with Intel TDX or AMD SEV-SNP hardware -- KataConfig deployed and in Ready state -- At least one kata pod successfully running (proves TEE is functional) -- `oc` CLI logged in to the cluster -- `jq` installed locally +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`. -### 3. Local Tools +### Bare Metal ```bash -# Check prerequisites -command -v oc && echo "✓ oc CLI installed" -command -v jq && echo "✓ jq installed" -oc whoami && echo "✓ Logged in to cluster" +# Collect firmware values from OCP release artifacts +make collect-firmware-refvals + +# Or with explicit OCP version: +./scripts/collect-firmware-refvals.sh --ocp-version 4.20.18 + +# Specify TEE type (default: tdx): +./scripts/collect-firmware-refvals.sh --tee snp --ocp-version 4.20.18 ``` -## Workflow +Output: `~/.coco-pattern/firmware-reference-values.json` -The firmware collection workflow is fully automated via a single command: +Veritas resolves the kata-containers and edk2-ovmf RPMs from the OCP release payload (pinned by digest) and computes the expected firmware hashes. -### Step 1: Collect Firmware Reference Values +### Script Options ```bash -# From the coco-pattern repository root: -make collect-firmware-refvals -``` +./scripts/collect-firmware-refvals.sh --help -This command: - -1. Launches a kata pod with `RuntimeClass: kata-cc` -2. Installs veritas inside the pod -3. Collects firmware measurements from the TEE -4. Transforms output to RVPS format (JSON with arrays) -5. Saves to `~/.coco-pattern/firmware-reference-values.json` -6. Cleans up the pod - -**Output format** (`~/.coco-pattern/firmware-reference-values.json`): - -```json -{ - "mr_td": ["a1b2c3d4..."], - "rtmr_1": ["e5f6a7b8..."], - "rtmr_2": ["c9d0e1f2..."], - "snp_launch_measurement": ["f3e4d5c6..."], - "xfam": ["e742060000000000"] -} +Options: + --platform Platform: baremetal (default) or azure + -o, --output Override output path + -p, --pull-secret Pull secret file (default: ~/pull-secret.json) + -v, --ocp-version OCP version (baremetal; default: auto-detect) + --osc-version OSC operator version (azure; default: auto-detect) + -t, --tee TEE type (default: tdx) ``` -**Key points:** +## Loading Values to Vault -- Each field is an **array** of strings (supports multiple valid values) -- Hash values are lowercase hex strings (SHA-384 = 96 hex chars for TDX/SNP firmware) -- Empty arrays `[]` mean "not available" - attestation will skip that check -- Only populated fields for the detected TEE type (TDX or SNP) +### Step 1: Configure values-secret.yaml -### Step 2: Enable in values-secret.yaml +Azure reference values use the `pcrStash` secret (already enabled by default in `~/values-secret-coco-pattern.yaml`). -Uncomment the `firmwareReferenceValues` section in `~/values-secret-coco-pattern.yaml`: +Bare metal reference values use the `firmwareReferenceValues` secret. Uncomment this section in `~/values-secret-coco-pattern.yaml`: ```yaml - name: firmwareReferenceValues @@ -92,225 +86,84 @@ Uncomment the `firmwareReferenceValues` section in `~/values-secret-coco-pattern path: ~/.coco-pattern/firmware-reference-values.json ``` -### Step 3: Load Secrets to Vault +### Step 2: Push to Vault ```bash make load-secrets ``` -The validated patterns framework reads `values-secret-coco-pattern.yaml` and pushes firmware values to Vault at `secret/data/hub/firmwareReferenceValues`. - -### Step 4: Verify Upload +### Step 3: Verify (optional) ```bash -# Check the secret was written to Vault -vault kv get secret/hub/firmwareReferenceValues -``` +# Check Vault +vault kv get secret/hub/firmwareReferenceValues # bare metal +vault kv get secret/hub/pcrStash # azure -Expected output shows a single `json` key containing the full JSON object. - -### Step 5: Deploy/Sync KBS - -If the KBS cluster is already running: - -```bash -# Force ExternalSecret to re-sync from Vault -oc delete externalsecret firmware-refvals-eso -n trustee-operator-system - -# Verify the secret synced -oc get secret firmware-reference-values -n trustee-operator-system - -# Check RVPS ConfigMap contains firmware entries +# Check RVPS ConfigMap on cluster oc get configmap rvps-reference-values -n trustee-operator-system -o yaml ``` -If deploying fresh: +If updating an existing deployment, force the ExternalSecret to re-sync: ```bash -make install +oc delete externalsecret firmware-refvals-eso -n trustee-operator-system # bare metal +oc delete externalsecret pcrs-eso -n trustee-operator-system # azure ``` -The RVPS will automatically reload reference values from the `rvps-reference-values` ConfigMap. - -## Multi-OCP-Version Support - -Different OpenShift versions may have different firmware measurements due to kernel/initrd changes. To support multiple versions: - -1. **Collect from each version:** +## Multi-Version Support - ```bash - # OCP 4.18 cluster - make collect-firmware-refvals - - # OCP 4.19 cluster - make collect-firmware-refvals-merge - ``` - -2. **The merge automatically deduplicates:** - - The `--merge` flag (used by `collect-firmware-refvals-merge`) reads the existing file, unions the arrays, and deduplicates: - - ```json - { - "mr_td": ["<4.18-value>", "<4.19-value>"], - "rtmr_2": ["<4.18-kernel>", "<4.19-kernel>"] - } - ``` - -3. **Load merged values to Vault:** - - ```bash - make load-secrets - ``` - -The attestation policy uses `in` checks - a pod passes if its measurement matches **any** value in the array. - -## Advanced Options - -The collection script supports several options: +Different OCP versions (bare metal) or OSC versions (Azure) may ship different artifacts. To support multiple versions, collect for each version and the values will be merged into arrays: ```bash -# Merge with existing file -./scripts/collect-firmware-refvals.sh --merge - -# Use different namespace for collection pod -./scripts/collect-firmware-refvals.sh --namespace my-namespace - -# Override output file -./scripts/collect-firmware-refvals.sh --output /custom/path/firmware.json - -# Use different RuntimeClass (for peer-pods/Azure) -./scripts/collect-firmware-refvals.sh --runtime-class kata-remote - -# Use custom base image -./scripts/collect-firmware-refvals.sh --pod-image myregistry.io/custom-ubi9:latest - -# Show all options -./scripts/collect-firmware-refvals.sh --help +# Bare metal: run once per OCP version +./scripts/collect-firmware-refvals.sh --ocp-version 4.20.15 -o /tmp/fw-4.20.15.json +./scripts/collect-firmware-refvals.sh --ocp-version 4.20.18 -o /tmp/fw-4.20.18.json +# Manually merge with jq or re-run with all versions via veritas directly ``` -## Known Limitations (Veritas Gaps) - -As of veritas 0.2.0, the following are **not** collected and must be added manually if needed: - -### 1. TCB Version Numbers - -Veritas does not extract minimum TCB version numbers (bootloader, microcode, SNP, TEE). These are available in the attestation evidence but not in the veritas JSON output. - -**Workaround:** Extract from attestation quotes manually if needed. Add to the JSON file as: - -```json -{ - "tcb_bootloader_min": "3", - "tcb_snp_min": "20", - "tcb_microcode_min": "115" -} -``` - -Then update the attestation policy to check: - -```rego -input.snp.report.reported_tcb.bootloader >= tcb_bootloader_min -``` - -### 2. SNP Policy Bits - -The SNP guest policy contains multiple flags (smt_allowed, migrate_ma, debug, etc.). Veritas reports the full policy word but does not break it into individual enforcement rules. - -To enforce specific policy bits, add to attestation policy: - -```rego -input.snp.report.policy.smt_allowed == false -input.snp.report.policy.debug == false -``` - -### 3. Container Image Measurements - -Veritas does not measure the application container image digest. Image policy enforcement is handled separately via: - -- Confidential Data Hub (CDH) pulling image from KBS -- Kyverno policies validating image signatures (cosign, Notary) - -## Troubleshooting - -### Collection script fails to launch pod - -**Symptom:** `oc apply` fails or pod stuck in Pending - -**Check:** - -- RuntimeClass `kata-cc` exists: `oc get runtimeclass kata-cc` -- KataConfig is Ready: `oc get kataconfig kata-config` -- Node has sufficient resources - -### Veritas collection fails - -**Symptom:** `veritas collect` returns empty or errors - -**Check:** - -1. Pod is using correct RuntimeClass (kata-cc for bare metal) -2. Pod is actually running on bare metal hardware (not Azure peer-pods) -3. TEE device exists inside pod: `oc exec -- ls /dev/tdx_guest` (TDX) or `ls /dev/sev` (SNP) -4. Veritas installed correctly: `oc exec -- veritas --version` - -### KBS attestation still passes without firmware values - -**Expected behavior:** The attestation policy has backwards-compatible fallback rules. If no firmware reference values are in RVPS, the policy only checks `init_data`. - -To **enforce** firmware, remove the fallback rules from `attestation-policy.yaml`: - -```rego -# Remove these "hardware := 2 if count(query_reference_value(...)) == 0" rules -``` - -### Hash mismatch after cluster upgrade - -**Cause:** Kernel/firmware updated, changing rtmr_2 or mr_td - -**Fix:** Re-collect firmware values from upgraded cluster, merge into existing file: - -```bash -make collect-firmware-refvals-merge -make load-secrets -``` +The attestation policy uses `in` (set membership) — a workload passes if its measurement matches **any** value in the array. ## SHA-256 vs SHA-384 -You may notice different hash algorithms in different contexts: - -- **init_data TOML**: SHA-256 (CoCo initdata spec, used for PCR8 extend) -- **Bare metal TDX firmware**: SHA-384 (Intel TDX architecture requirement) -- **Bare metal SNP firmware**: SHA-384 (AMD SEV-SNP architecture requirement) -- **Azure vTPM PCRs**: SHA-256 +Different hash algorithms are used at different layers: -These are **correct** - they're different mechanisms at different layers. The attestation policy checks these independently. +- **Azure vTPM PCRs**: SHA-256 (TPM 2.0 standard) +- **Bare metal TDX firmware**: SHA-384 (Intel TDX architecture) +- **Bare metal SNP firmware**: SHA-384 (AMD SEV-SNP architecture) +- **init_data TOML**: SHA-256 (CoCo initdata spec) -## Security Considerations +These are correct — the attestation policy checks them independently. -### Threat Model +## Attestation Policy Coverage -Firmware reference values protect against: +The following table maps what veritas provides vs what the attestation policy checks: -- Unauthorized firmware modifications (malicious OVMF, compromised bootloader) -- Kernel tampering (different kernel than expected) -- Debug mode enabled (allows memory inspection via hypervisor) +| Check | Bare Metal TDX | Bare Metal SNP | Azure TDX | Azure SNP | +|-------|---------------|---------------|-----------|-----------| +| Firmware (OVMF) | mr_td | (part of launch measurement) | mr_td | (part of measurement) | +| Launch digest | - | snp_launch_measurement | - | measurement | +| Kernel+initrd | rtmr_1 | (part of launch measurement) | pcr09 | pcr09 | +| Kernel cmdline | rtmr_2 | (part of launch measurement) | pcr11 | pcr11 | +| CPU features | xfam | - | xfam | - | +| Debug disabled | Policy hardcoded | Policy hardcoded | - | - | +| TEE type | Policy hardcoded | - | Policy hardcoded | - | +| Init data | Computed by imperative job | Computed by imperative job | Computed by imperative job | Computed by imperative job | -Choose the level appropriate for your threat model. +## Known Limitations -### Debug Mode +As of the coco-tools 1.12 container: -The attestation policy enforces `debug == false` for both TDX and SNP. Debug mode allows: +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. +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). -- Memory inspection via hypervisor -- Single-stepping the guest -- Extracting secrets from guest memory +## Security Considerations -**Production workloads must run with debug disabled.** If attestation fails due to debug mode, do not disable the check - fix the KataConfig to disable debug. +The attestation policy enforces `debug == false` for both TDX and SNP. Debug mode allows memory inspection via the hypervisor and must never be enabled for production workloads. ## References -- [Veritas Documentation](https://github.com/confidential-containers/veritas) -- [Intel TDX Attestation Spec](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html) -- [AMD SEV-SNP Attestation Spec](https://www.amd.com/en/developer/sev.html) -- [Trustee Attestation Policy Reference](https://github.com/openshift/trustee-operator/tree/main/config/templates) +- [Veritas](https://github.com/confidential-devhub/veritas) — reference value computation tool +- [Trustee Attestation Policy](https://github.com/openshift/trustee-operator/tree/main/config/templates) — upstream default policy +- [Intel TDX Spec](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html) +- [AMD SEV-SNP Spec](https://www.amd.com/en/developer/sev.html) diff --git a/values-baremetal-gpu.yaml b/values-baremetal-gpu.yaml index a70a1e57..af788dcf 100644 --- a/values-baremetal-gpu.yaml +++ b/values-baremetal-gpu.yaml @@ -189,7 +189,7 @@ clusterGroup: name: sandbox-policies namespace: openshift-sandboxed-containers-operator chart: sandboxed-policies - chartVersion: 0.1.* + chartVersion: 0.2.* kbs-access: name: kbs-access diff --git a/values-baremetal.yaml b/values-baremetal.yaml index edfe97ff..76711bcb 100644 --- a/values-baremetal.yaml +++ b/values-baremetal.yaml @@ -162,7 +162,7 @@ clusterGroup: name: sandbox-policies namespace: openshift-sandboxed-containers-operator chart: sandboxed-policies - chartVersion: 0.1.* + chartVersion: 0.2.* kbs-access: name: kbs-access diff --git a/values-simple.yaml b/values-simple.yaml index 28d682fd..723746b7 100644 --- a/values-simple.yaml +++ b/values-simple.yaml @@ -92,7 +92,7 @@ clusterGroup: name: sandbox-policies namespace: openshift-sandboxed-containers-operator #upstream config chart: sandboxed-policies - chartVersion: 0.1.* + chartVersion: 0.2.* overrides: - name: global.coco.azure.tags value: "key1=value1,key2=value2" diff --git a/values-trusted-hub.yaml b/values-trusted-hub.yaml index 160623b6..719e2ca0 100644 --- a/values-trusted-hub.yaml +++ b/values-trusted-hub.yaml @@ -74,7 +74,7 @@ clusterGroup: name: sandbox-policies namespace: openshift-sandboxed-containers-operator #upstream config chart: sandboxed-policies - chartVersion: 0.1.* + chartVersion: 0.2.* overrides: - name: global.coco.azure.tags value: "key1=value1,key2=value2" From 2401cec5bea52eb0430ccc34b94028468b591275 Mon Sep 17 00:00:00 2001 From: Chris Butler Date: Tue, 2 Jun 2026 13:28:01 +0800 Subject: [PATCH 2/2] fix: address linter error and update README - Fix AGENTS.md: capitalize "Git" (textlint terminology rule) - Fix README.md: correct topology count (four, not three) - Fix README.md: update RHDP description to say "reference value collection" - Add version history for v5.3 through v5.6 releases Co-Authored-By: Claude Opus 4.6 (1M context) --- AGENTS.md | 2 +- README.md | 8 ++++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index b99090a0..6bad2fdc 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -62,7 +62,7 @@ These charts are published independently and consumed from the `charts.validated | `sandboxed-policies` | `validatedpatterns/sandboxed-policies-chart` | ACM policies hub → spoke | | `sandboxed-containers` | `validatedpatterns/sandboxed-containers-chart` | Sandboxed runtime on spoke | -Changes to companion charts require a release (git tag) before the pattern can consume them. Update the `chartVersion:` field in the values files to pick up new releases. +Changes to companion charts require a release (Git tag) before the pattern can consume them. Update the `chartVersion:` field in the values files to pick up new releases. ## Cluster Groups diff --git a/README.md b/README.md index 6151fbba..de7c94b6 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ Confidential containers use hardware-backed Trusted Execution Environments (TEEs ## Topologies -The pattern provides three deployment topologies: +The pattern provides four deployment topologies: 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. @@ -29,6 +29,10 @@ Breaking change from v4. Uses GA releases of the CoCo stack with Kyverno-based i - **5.0** — Kyverno-based `cc_init_data` injection (replaces MutatingAdmissionPolicy), OSC 1.12 / Trustee 1.1 GA, external chart repositories, self-signed certificates via cert-manager, multi-cluster support via ACM. Requires OCP 4.19.28+. - **5.1** — Bare metal support for Intel TDX and AMD SEV-SNP via NFD auto-detection. Currently tested on SNO (Single Node OpenShift) configurations only. - **5.2** — NVIDIA H100 confidential GPU support for bare metal (`baremetal-gpu` clusterGroup). Adds GPU Operator, IOMMU configuration, CC Manager, and sample CUDA workload. +- **5.3** — DRY refactor of trustee and kyverno overrides, Kyverno CRD label fix, pattern infrastructure update. +- **5.4** — Firmware reference values workflow for bare metal attestation via veritas. Adds `collect-firmware-refvals.sh`, RVPS integration, and hardened attestation policy (trustee-chart v0.5.0). +- **5.5** — Trustee-chart v0.7.0 (td_attributes.debug path fix). Unified reference value collection for Azure and bare metal via veritas container. +- **5.6** — Documentation update, sandboxed-policies v0.2.0 (Azure-conditional peer-pods). ### Previous versions @@ -176,4 +180,4 @@ Deployment commands: - Single cluster: `bash rhdp/wrapper.sh ` (e.g. `bash rhdp/wrapper.sh eastasia`) - Multi-cluster: `bash rhdp/wrapper-multicluster.sh ` -The wrapper scripts handle cluster provisioning via `openshift-install`, secret generation, PCR retrieval, and pattern installation. +The wrapper scripts handle cluster provisioning via `openshift-install`, secret generation, reference value collection, and pattern installation.