coco: initial integration for Confidential Containers and Trustee operators#80
coco: initial integration for Confidential Containers and Trustee operators#80beraldoleal wants to merge 7 commits intovalidatedpatterns:mainfrom
Conversation
29c9c84 to
341c962
Compare
5074bb3 to
74e2c74
Compare
8b9a6cf to
67509bc
Compare
sabre1041
left a comment
There was a problem hiding this comment.
This is a good start. A few issues that have arisen during the review
- ZTWIM GA reconciles changes so the imperative configurations applied here are reverted immediately
- There is no mention about applying labels to nodes. Otherwise the sample workload fails to be scheduled
- There should be a callout about the instance types that may need to be configured. I tested in
eastasiaregion and the configured instance was not available - Additional comments inline
values-secret.yaml.template
Outdated
| onMissingValue: generate | ||
| vaultPolicy: alphaNumericPolicy | ||
|
|
||
| # CoCo (Confidential Containers) secrets |
There was a problem hiding this comment.
Shouldnt all of the coco related secrets be commented out by default and include instructions on what secrets should be uncommented when in use?
values-secret.yaml.template
Outdated
| vaultPrefixes: | ||
| - global | ||
| fields: | ||
| - name: id_rsa.pub |
There was a problem hiding this comment.
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?
We fixed it by adding CREATE_ONLY_MODE=true env var to the ZTWIM operator via OLM subscription config in values-coco-dev.yaml
I will add a proper CONFIDENTIAL-CONTAINERS.md file. |
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>
67509bc to
5c16b3c
Compare
|
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. |
Vide individual commits for messages.