coco: initial integration for Confidential Containers and Trustee operators #80
Conversation
| default UpdateInterfaceRequest := true | ||
| default UpdateRoutesRequest := true | ||
| default WaitProcessRequest := true | ||
| default WriteStreamRequest := true |
There was a problem hiding this comment.
It might be a good idea to extend the policy to reflect the latest 1.11 example - https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_confidential_containers/deploying-cc_azure-cc#creating-initdat_azure-cc.
Specifically adding this
ExecProcessRequest if {
input_command = concat(" ", input.process.Args)
some allowed_command in policy_data.allowed_commands
input_command == allowed_command
}
policy_data := {
"allowed_commands": [
"curl http://127.0.0.1:8006/cdh/resource/default/attestation-status/status"
]
}
This will make verifying the attestation status easier withou the need to use a permissive policy.
It also needs a change in the Trustee config to add the attestation-status secret.
| # It does not contain the secrets themselves, only references to Vault paths. | ||
| kbs: | ||
| secretResources: | ||
| - name: "kbsres1" |
There was a problem hiding this comment.
we can use attestation-status instead of kbsres1 - https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.11/html/deploying_red_hat_build_of_trustee/deploying-trustee_azure-trustee#creating-attestation-token-secrets_azure-trustee
| installPlanApproval: Automatic | ||
| main: | ||
| clusterGroupName: hub | ||
| clusterGroupName: coco-dev |
There was a problem hiding this comment.
I think we need to leave this the same for the actual PR.
There was a problem hiding this comment.
Yes, it here, but I will drop when removing the draft flag.
There was a problem hiding this comment.
This will need to be set back to hub now that we are out of draft status
beraldoleal
force-pushed
the
integration-v2
branch
13 times, most recently
from
29c9c84 to
341c962
Compare
| definition: | ||
| metadata: | ||
| annotations: | ||
| ztwim.openshift.io/create-only: "true" |
There was a problem hiding this comment.
@sabre1041 - Could you have a look this. Give your comfort level given coco will be an optional feature right now?
beraldoleal
force-pushed
the
integration-v2
branch
10 times, most recently
from
5074bb3 to
74e2c74
Compare
beraldoleal
force-pushed
the
integration-v2
branch
10 times, most recently
from
4673d28 to
8b9a6cf
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>
beraldoleal
force-pushed
the
integration-v2
branch
from
8b9a6cf to
67509bc
Compare
sabre1041
left a comment
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
| installPlanApproval: Automatic | ||
| main: | ||
| clusterGroupName: hub | ||
| clusterGroupName: coco-dev |
There was a problem hiding this comment.
This will need to be set back to hub now that we are out of draft status
| 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?
| 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?
| options: | ||
| useCSV: false | ||
| syncPolicy: Automatic | ||
| installPlanApproval: Automatic |
There was a problem hiding this comment.
Also need to set autoApproveManualInstallPlans: true otherwise operators do not get installed
4 participants
Vide individual commits for messages.