coco: initial integration for Confidential Containers and Trustee operators#80
Conversation
beraldoleal
force-pushed
the
integration-v2
branch
13 times, most recently
from
29c9c84 to
341c962
Compare
beraldoleal
force-pushed
the
integration-v2
branch
10 times, most recently
from
5074bb3 to
74e2c74
Compare
beraldoleal
force-pushed
the
integration-v2
branch
2 times, most recently
from
a67a701 to
c40eff1
Compare
|
@sabre1041 @butler54 @bpradipt no more fork references. Its using now the official validatedpatterns/charts release versions. |
butler54
left a comment
butler54
left a comment
There was a problem hiding this comment.
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.
| --- | ||
|
|
There was a problem hiding this comment.
Flag for future work - We should create an issue to add this playbook to the VP ansible collection. @mhjacks
| 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 |
There was a problem hiding this comment.
Did you get the python script to demonstrably work? This needs to be backported into the coco-pattern to avoid a custom container.
There was a problem hiding this comment.
yes, this works. And that is the plan.
beraldoleal
force-pushed
the
integration-v2
branch
3 times, most recently
from
ee81a09 to
107cf46
Compare
sabre1041
left a comment
sabre1041
left a comment
There was a problem hiding this comment.
Initial set of feedbac
beraldoleal
force-pushed
the
integration-v2
branch
from
107cf46 to
0111b8c
Compare
|
@sabre1041 thanks for the review, sent a force push with your suggestions. Feel free to reopen or send more comments. |
beraldoleal
force-pushed
the
integration-v2
branch
from
0111b8c to
fecd27a
Compare
butler54
left a comment
butler54
left a comment
There was a problem hiding this comment.
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 |
beraldoleal
force-pushed
the
integration-v2
branch
2 times, most recently
from
198af38 to
007efa8
Compare
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>
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
sabre1041
left a comment
sabre1041
left a comment
There was a problem hiding this comment.
@beraldoleal @butler54 This is looking good at this point. There is one minor issue with duplicate resources being created as part of the as part of the imperative actions. It is not a blocking issue that blocks this integration from moving forward. @beraldoleal please do create an issue for us to track.
Thanks a lot guys and great work!
4 participants
Vide individual commits for messages.