search

confidential-containers / trustee

Attestation and Secret Delivery Components
Apache License 2.0
64 stars 83 forks source link

RFC: Trustee CLI #529

Open fitzthum opened 3 days ago

fitzthum commented 3 days ago

We should consider introducing a new tool, maybe called Trustee CLI, that supports a wide range of functions.

Here are some things it could do.

  1. Everything that KBS Client does We could extend KBS Client, but I think we might want to keep that tool small in scope. We could also leave out the ability to request resources (and all the attester dependencies), since the CLI wouldn't be called from inside a guest.
  2. RVPS provisioning We have a separate tool to provision reference values. IMO this should be deleted and moved into another tool.
  3. Provisioning Trustee itself We have a script to deploy Trustee in k8s and a guide to use docker compose. Why not unify these with a tool that allows users to deploy Trustee with one command. The CLI would also generate the keypairs (which you still have to do manually when using docker compose). Since the CLI would generate the keys, it could also keep track of them for later when the user wants to configure Trustee (later commands wouldn't require specifying the certs). We should consider how this might overlap with the Trustee operator.
  4. Provisioning Trustee in CoCo As an extension of the last point, the CLI could also allow a user to deploy Trustee as a CoCo workload with one command. This is a little bit trickier, but it's something we've wanted to support for a long time. The deployment command would be somewhat long running. It would start a pod with the needed runtime classes (and probably sealed secrets to provision various keypairs). The workload would be configured to use the CLI itself as its KBS. The CLI's start confidential cluster command would block until it receives an attestation, which it would somehow fulfill locally. We can discuss this in more detail separately. It's going to be a bit tricky, but I think we have to implement something like this eventually.
  5. Encrypting images We have a CoCo keyprovider tool in guest-components, but it's hard to find and somewhat hard to use. It's arguable that this more related to the workload and should not be part of a KBS tool, but I think it could make sense to add it, especially if it's going to automatically push keys to the KBS.
  6. Sealing secrets Again, we have a tool in guest components for this, but it's hard to find; very similar considerations as the above.
  7. Plugin front-end Our new plugin interface will require some support in admin-facing tooling. This could be as simple as letting an admin provide arbitrary POST requests, but we could also implement a front-end plugin interface that would allow different plugins to define their own logic for generating admin requests from commands. This probably isn't necessary in the short term.
  8. Status Currently the only way to figure out what is happening with Trustee and the guests that contact it is to stare at the logs. We should think about creating a more friendly interface. We could do this by parsing the logs into a nicer format or we could introduce more sophisticated interfaces to Trustee.

Obviously this is a huge amount of work. We could implement these things incrementally. Hopefully we can reuse a lot of code and rely on the crates that we already surface.

I think we should at least start thinking about unifying the admin experience and creating flows that are easy enough for real people to use. What I am describing here could also serve as a kubectl plugin, which is something we have discussed for a long time.

ChengyuZhu6 commented 2 days ago

I fully support this proposal. And I have an idea: we can create a new repository (for example, named cli) to store and test the clients of all components in guest-components and trustee , as well as the integrated client, ensuring that all clients work properly. The advantages of this approach are as follows:

  1. The client that integrates all components’ clients (such as trustee-client mentioned in the proposal) will have a suitable repository. And guest-components and trustee repositories will continue to focus on service functionalities.
  2. We can pre-configure a simulated attestation environment in CI to test and verify the functions of all clients and generate a workload for deploying trustee.
  3. Since many cloud-native components are primarily written in Go, we can support different language versions of these clients. This will allow the clients to be directly integrated into cloud-native components (such as using the CDH go client in containerd’s NRI), thereby promoting the use of guest-components and trustee.

WDYT? @fitzthum @Xynnn007 @jialez0 @jiazhang0 @BbolroC @huoqifeng and anyone else who is interested.