Skip to content

coco: initial integration for Confidential Containers and Trustee operators#80

Open
beraldoleal wants to merge 7 commits intovalidatedpatterns:mainfrom
beraldoleal:integration-v2
Open

coco: initial integration for Confidential Containers and Trustee operators#80
beraldoleal wants to merge 7 commits intovalidatedpatterns:mainfrom
beraldoleal:integration-v2

Conversation

@beraldoleal
Copy link

@beraldoleal beraldoleal commented Dec 8, 2025

Vide individual commits for messages.

@beraldoleal beraldoleal force-pushed the integration-v2 branch 13 times, most recently from 29c9c84 to 341c962 Compare December 10, 2025 23:06
@beraldoleal beraldoleal force-pushed the integration-v2 branch 10 times, most recently from 5074bb3 to 74e2c74 Compare December 17, 2025 01:08
@beraldoleal beraldoleal marked this pull request as ready for review December 17, 2025 01:08
@butler54 butler54 self-requested a review December 17, 2025 01:37
@beraldoleal beraldoleal force-pushed the integration-v2 branch 11 times, most recently from 8b9a6cf to 67509bc Compare December 17, 2025 19:49
Copy link
Collaborator

@sabre1041 sabre1041 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start. A few issues that have arisen during the review

  1. ZTWIM GA reconciles changes so the imperative configurations applied here are reverted immediately
  2. There is no mention about applying labels to nodes. Otherwise the sample workload fails to be scheduled
  3. 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
  4. Additional comments inline

onMissingValue: generate
vaultPolicy: alphaNumericPolicy

# CoCo (Confidential Containers) secrets
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldnt all of the coco related secrets be commented out by default and include instructions on what secrets should be uncommented when in use?

vaultPrefixes:
- global
fields:
- name: id_rsa.pub
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the instructions here, where does it describe creating both these secrets and the secrets for trestee in the ~/.config/validated-patterns/trustee directory?

@beraldoleal
Copy link
Author

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 and others added 7 commits March 2, 2026 12:59
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>
Signed-off-by: Beraldo Leal <bleal@redhat.com>
Basic markdown file with deployment steps.

Signed-off-by: Beraldo Leal <bleal@redhat.com>
@beraldoleal
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants