Deploy Trustee inside CoCo

[fitzthum]

Can we use the Trustee operator (in conjunction with the CoCo operator) to deploy Trustee inside of CoCo?

The first step seems somewhat simple. We just need to add the appropriate runtime class to the pods.

The bigger question is how we avoid Trusting the trustee operator, which would be outside the enclave. We couldn't have it handle the secrets. Instead we would probably want sealed secrets or some kind of sidecar for that.

[bpradipt]

I think it's doable and also seems to be a practical way for hierarchical and distributed trustee setup. Using sealed secrets to provide bootstrapping configuration to one Trustee from another one.

[Xynnn007]

It would be very useful if we consider a hierarchical deployment of trustes, in which a top trustee verifies sub-trustees, and the sub-trustees serve as a cluster to serve other Pods with high availability. But it's important to note that this still doesn't eliminate the problem of root trust. There will always be a root node trustee trust problem that needs to be solved, it is either

Require users to deploy root Trustee in their own trusted domain, or
The deployment of Trustee itself allows users to initiate requests in the form of challenge-response to obtain the measurement values ​​of the target environment and compare them with community standard values. This way, we may additionally need a trustee-verify-client, which completes the connection to the deployed trustee, obtaining evidence and verification.

[fitzthum]

Yeah I am assuming Trustee inside coco would go hand-in-hand with a local version of Trustee that runs from the command line. Recently I've realized that the Trustee integration tests, which make a config for the KBS and then spin it up in the background, are very similar to what we would need from this sort of local Trustee. I think we can implement something like that without too much trouble.

[lmilleri]

Currently the trustee-operator provides the bootstrap configuration to trustee pods using configmaps (and secrets). For example, resource-policy, attestation-policy, reference values, etc. This config is confidential and it shouldn't be tampered with by the cluster admin. How to deal with this issue? Maybe the easiest solution is to fetch the config from the primary trustee as sealed secrets. Or should we consider other approaches like:

• External Secret Management Systems with Runtime Provisioning,
• Kubernetes Secrets Store CSI Driver with External Secret Providers
• init-data ?

[fitzthum]

Sealed secrets are one option for provisioning Trustee. They only support writing data to the workload. This could be a good fit for setting up resources, but if we want to support adding more resources at runtime via the Trustee admin API, we probably need some shared storage backend. We could use a KMS for this or possibly some kind of shared encrypted storage, although this is not yet supported in coco. There are similar considerations for policies.

It might simplify things to only allow configuration of Trustee from one of the replicas or to use a separate interface entirely.