coco: initial integration for Confidential Containers and Trustee operators by beraldoleal · Pull Request #80 · validatedpatterns/layered-zero-trust

beraldoleal · 2025-12-08T22:38:42Z

Vide individual commits for messages.

ansible/initdata-default.toml.tpl

overrides/values-trustee.yaml

ansible/configure-spire-server-x509pop.yaml

values-global.yaml

ansible/configure-spire-server-x509pop.yaml

values-global.yaml

beraldoleal · 2026-03-02T16:39:27Z

ZTWIM GA reconciles changes so the imperative configurations applied here are reverted immediately

We fixed it by adding CREATE_ONLY_MODE=true env var to the ZTWIM operator via OLM subscription config in values-coco-dev.yaml

There is no mention about applying labels to nodes. Otherwise the sample workload fails to be scheduled
We removed the nodeSelector entirely. Peer pods run as VMs, not on worker nodes directly, so the label it was unnecessary for now.

There should be a callout about the instance types that may need to be configured. I tested in eastasia region and the configured instance was not available

I will add a proper CONFIDENTIAL-CONTAINERS.md file.

beraldoleal · 2026-03-02T18:02:20Z

Hey @sabre1041, @butler54 , @bpradipt ... let's give this a second shot! I addressed all the comments from the previous review. Feel free to reopen any or add new ones.

This was tested on Azure with AMD SEV-SNP (DCasv6 / Genoa), OCP 4.20.8, using the ZTWIM operator stable-v1 channel, sandbox operator v1.11.0, and trustee operator v1.0.0.

The chart references still point to custom branches.... waiting for @butler54 's PRs. Once those PRs merge, I will update the references. Hopefully that won't be a blocker for review.

beraldoleal · 2026-03-06T15:19:38Z

@sabre1041 @butler54 @bpradipt no more fork references. Its using now the official validatedpatterns/charts release versions.

butler54

There are a few hardcoded vars that definitely need to change.
The biggest question is the use of the imperative framework to generate certificates. If this can be moved to generation in cert manager I think that would be more 'kube friendly'

The justification for this is the imperative framework is always the second last option (the last option being a work done on the developer workstation.

butler54 · 2025-12-17T01:38:32Z

ansible/azure-nat-gateway.yaml

+---
+


Flag for future work - We should create an issue to add this playbook to the VP ansible collection. @mhjacks

ansible/initdata-default.toml.tpl

overrides/values-trustee.yaml

ansible/install-deps.yaml

values-coco-dev.yaml

butler54 · 2026-03-10T07:16:38Z

ansible/generate-certs.yaml

+# Generate SPIRE x509pop certificates for CoCo integration
+# Creates CA certificate and agent certificates for all workloads
+
+- name: Generate SPIRE x509pop certificates


I want to check here whether we should be using certificate manager or the ansible approach here.

To me this would make a lot more sense (if we can) do use cert manager then we'd have less janking around to get things done (still a non-zero amount of janking).

Agree cert-manager would be cleaner. went the imperative route to unblock testing faster. the main friction is SPIRE expects the CA as a ConfigMap and cert-manager outputs Secrets. will explore in a follow-up PR.

charts/hello-coco/templates/pod.yaml

butler54 · 2026-03-10T07:24:14Z

ansible/init-data-gzipper.yaml

+      ansible.builtin.shell: |
+        hash=$(sha256sum "{{ rendered_path }}" | cut -d' ' -f1)
+        initial_pcr=0000000000000000000000000000000000000000000000000000000000000000
+        echo -n "$initial_pcr$hash" | python3 -c "import sys,hashlib; print(hashlib.sha256(bytes.fromhex(sys.stdin.read())).hexdigest())"
+      register: pcr8_hash


Did you get the python script to demonstrably work? This needs to be backported into the coco-pattern to avoid a custom container.

yes, this works. And that is the plan.

sabre1041

Initial set of feedbac

values-coco-dev.yaml

beraldoleal · 2026-03-16T19:31:44Z

@sabre1041 thanks for the review, sent a force push with your suggestions. Feel free to reopen or send more comments.

butler54

@beraldoleal.

The original intent of doing this offline was it was an 'as expected' deployment measured from a trusted zone as to what the RVPS values and the deployment should be.

I'm wondering whether rather than changing the script we could do this via a --online flag (e.g. check as deployed).

WDYT

beraldoleal · 2026-03-16T22:59:19Z

@beraldoleal.

The original intent of doing this offline was it was an 'as expected' deployment measured from a trusted zone as to what the RVPS values and the deployment should be.

I'm wondering whether rather than changing the script we could do this via a --online flag (e.g. check as deployed).

WDYT

I see, well then I would say to use --osc-version instead. Doesn't query the cluster and its intent based. But then we will start creating two things to do the same calculation, so maybe evaluate the usage of veritas here? If straight forward good, if not we can stick with get-pcr.sh --osc-version for now and evaluate using it later? wdyt?

This adds initial integration for Confidential Containers and Trustee Operators as a separated clustergroup. Co-authored-by: Chris Butler <chris.butler@redhat.com> Signed-off-by: Beraldo Leal <bleal@redhat.com>

Add automated configuration for SPIRE Server x509pop NodeAttestor plugin required for CoCo peer-pods attestation. CoCo peer-pods run on untrusted cloud infrastructure. Using k8s_psat would require trusting the cloud provider's cluster. Instead, pods perform hardware TEE attestation to KBS to obtain x509 certificates as cryptographic proof of running in genuine confidential hardware, then use x509pop to register with SPIRE. The Red Hat SPIRE Operator's SpireServer CRD does not expose x509pop configuration, requiring a ConfigMap patch via this imperative job. Signed-off-by: Beraldo Leal <bleal@redhat.com>

Add hello-coco Helm chart demonstrating SPIRE agent deployment in confidential containers using x509pop node attestation. The chart deploys a test pod in a CoCo peer-pod (confidential VM with AMD SNP or Intel TDX) that fetches SPIRE agent certificates from KBS after TEE attestation, establishing hardware as the root of trust instead of Kubernetes. The pod contains three containers: init container fetches sealed secrets from KBS, SPIRE agent uses x509pop for node attestation, and test workload receives SPIFFE SVIDs via unix attestation. This validates the complete integration flow between ZTVP and CoCo components. Note: This could be dropped, if we stick with only the todoapp. Signed-off-by: Beraldo Leal <bleal@redhat.com>

Signed-off-by: Beraldo Leal <bleal@redhat.com>

Basic markdown file with deployment steps. Signed-off-by: Beraldo Leal <bleal@redhat.com>

Peer-pods don't have access to the node's pull-secret, needed for private repos. Use ESO kubernetes provider to sync pull-secret from openshift-config to the workload namespace. Signed-off-by: Beraldo Leal <bleal@redhat.com>

bpradipt reviewed Dec 9, 2025

View reviewed changes

ansible/initdata-default.toml.tpl Outdated Show resolved Hide resolved

bpradipt reviewed Dec 9, 2025

View reviewed changes

overrides/values-trustee.yaml Outdated Show resolved Hide resolved

bpradipt reviewed Dec 9, 2025

View reviewed changes

ansible/configure-spire-server-x509pop.yaml Outdated Show resolved Hide resolved

butler54 mentioned this pull request Dec 9, 2025

Update initdata for 1.11 validatedpatterns/coco-pattern#65

Open

butler54 reviewed Dec 9, 2025

View reviewed changes

values-global.yaml Outdated Show resolved Hide resolved

beraldoleal force-pushed the integration-v2 branch 13 times, most recently from 29c9c84 to 341c962 Compare December 10, 2025 23:06

butler54 reviewed Dec 11, 2025

View reviewed changes

ansible/configure-spire-server-x509pop.yaml Outdated Show resolved Hide resolved

beraldoleal force-pushed the integration-v2 branch 10 times, most recently from 5074bb3 to 74e2c74 Compare December 17, 2025 01:08

beraldoleal marked this pull request as ready for review December 17, 2025 01:08

sabre1041 reviewed Dec 22, 2025

View reviewed changes

values-global.yaml Show resolved Hide resolved

beraldoleal force-pushed the integration-v2 branch from 67509bc to 5c16b3c Compare March 2, 2026 18:00

beraldoleal requested review from bpradipt and sabre1041 March 2, 2026 18:02

beraldoleal force-pushed the integration-v2 branch 2 times, most recently from a67a701 to c40eff1 Compare March 6, 2026 14:58

butler54 requested changes Mar 10, 2026

View reviewed changes

beraldoleal force-pushed the integration-v2 branch 3 times, most recently from ee81a09 to 107cf46 Compare March 12, 2026 13:28

sabre1041 requested changes Mar 16, 2026

View reviewed changes

values-coco-dev.yaml Show resolved Hide resolved

values-coco-dev.yaml Outdated Show resolved Hide resolved

beraldoleal force-pushed the integration-v2 branch from 107cf46 to 0111b8c Compare March 16, 2026 19:31

beraldoleal force-pushed the integration-v2 branch from 0111b8c to fecd27a Compare March 16, 2026 20:27

butler54 reviewed Mar 16, 2026

View reviewed changes

beraldoleal force-pushed the integration-v2 branch 2 times, most recently from 198af38 to 007efa8 Compare March 17, 2026 15:07

beraldoleal and others added 8 commits March 20, 2026 17:38

coco: initial integration with ztvp

e838384

This adds initial integration for Confidential Containers and Trustee Operators as a separated clustergroup. Co-authored-by: Chris Butler <chris.butler@redhat.com> Signed-off-by: Beraldo Leal <bleal@redhat.com>

coco: update the values-secret template

97c2e35

Signed-off-by: Beraldo Leal <bleal@redhat.com>

coco: add get-pcr.sh script for attestation measurements

651fd68

coco: add get-secrets-coco.sh

6e1f10e

Signed-off-by: Beraldo Leal <bleal@redhat.com>

coco: adding confidential documentation

157d5f7

Basic markdown file with deployment steps. Signed-off-by: Beraldo Leal <bleal@redhat.com>

coco: automate pull-secret via ESO cross-namespace

c937b96

Peer-pods don't have access to the node's pull-secret, needed for private repos. Use ESO kubernetes provider to sync pull-secret from openshift-config to the workload namespace. Signed-off-by: Beraldo Leal <bleal@redhat.com>

beraldoleal force-pushed the integration-v2 branch from a481b09 to c937b96 Compare March 20, 2026 21:38

		---

Conversation

beraldoleal commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

beraldoleal commented Mar 2, 2026

Uh oh!

beraldoleal commented Mar 2, 2026

Uh oh!

beraldoleal commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

butler54 left a comment

Choose a reason for hiding this comment

Uh oh!

butler54 Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

butler54 Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

beraldoleal Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

butler54 Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

beraldoleal Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

sabre1041 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

beraldoleal commented Mar 16, 2026

Uh oh!

butler54 left a comment

Choose a reason for hiding this comment

Uh oh!

beraldoleal commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

beraldoleal commented Dec 8, 2025 •

edited

Loading

beraldoleal commented Mar 6, 2026 •

edited

Loading

beraldoleal Mar 11, 2026 •

edited

Loading

beraldoleal commented Mar 16, 2026 •

edited

Loading