RFC: Trustee CLI

[fitzthum]

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]

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.

[fitzthum]

We have two slightly conflicting interests here.

1. Create a tool that merges all our existing CoCo tooling and allows users to do anything they need to do with CoCo.
2. Create a tool that allows Trustee users (who might not be using CoCo) to do whatever they need to with Trustee.

I'm not totally sure how to reconcile these two things. It seems like we might need more than one tool. I think we could potentially get by with 3.

1. trustee-cli - This would replace kbs-client and would allow users to provision resources, start Trustee, get status, etc. This would also expose most of this functionality via a crate. This would live in the Trustee repo.
2. coco-ctl - This would replace the keyprovider and secret sealing tooling. It would allow users to create and deploy workloads. We would use this as a kubectl plugin and it would live in a new repo. It could also ues the trustee-cli as a crate to provide all of the Trustee tooling.
3. cc-kbc-client - This is the new tool that is proposed in the guest components repo. It can get resources but only using the KBS protocol.

There is an open question here. I am not sure if we should continue to support getting resources in the trustee-cli. Getting resources is not required for a client/admin configuring Trustee, but it is useful for testing. We could use the new cc-kbc-client to get resources instead, but only when using the cc-kbc. This would be fine for testing Trustee (we'd have to pull the guest components in the tests, but we could remove the gc dependency in the tools), but it wouldn't work for some of the other KMSes. So if we don't support getting resources in trustee-cli we wouldn't have a way to exercise the offline kbcs other than the CDH. Personally, I think that's fine but it would be a regression.

[spotlesstofu]

I'd like to add peer to peer attestation to the use cases.

That's for example when a developer uses the cloud to run AI. The developer wants to attest the cloud environment from their own laptop to safeguard their intellectual property.

Two possible directions:

• A "simple attestation tool" like @fitzthum suggests for RFC: Run Trustee inside of an enclave #542.
• Deploy Trustee in a local container environment.

[fitzthum]

@spotlesstofu

I am hoping that the Trustee-cli will be able to do very simple attestation of confidential workloads directly. A simple way to do this would be to just spin up Trustee locally but we could look at more sophisticated approaches where the CLI tool imports stuff from the KBS/AS and handles the attestation directly.

[wainersm]

We have two slightly conflicting interests here.

1. Create a tool that merges all our existing CoCo tooling and allows users to do anything they need to do with CoCo.

2. Create a tool that allows Trustee users (who might not be using CoCo) to do whatever they need to with Trustee.

I'm not totally sure how to reconcile these two things. It seems like we might need more than one tool. I think we could potentially get by with 3.

Reading the previous comments, I also don't know for sure how to reconcile but my feeling is that we will end up with a suite of tools rather than an one-rules-them-all beast.

1. **trustee-cli** - This would replace `kbs-client` and would allow users to provision resources, start Trustee, get status, etc. This would also expose most of this functionality via a crate. This would live in the Trustee repo.

As trustee is meant to be independent of CoCo, it makes sense that arrangement.

2. **coco-ctl** - This would replace the keyprovider and secret sealing tooling. It would allow users to create and deploy workloads. We would use this as a kubectl plugin and it would live in a new repo. It could also ues the `trustee-cli` as a crate to provide all of the Trustee tooling.

IMHO, any user-facing tool not meant exclusively for development/testing should be available in the confidential-confidential/confidential-containers repository as we don't want users jumping around repositories and documents. Ideally we should make the binaries available on the releases page (https://github.com/confidential-containers/confidential-containers/releases) in a coco-tools-.tgz file.

I tend to think that we should have one tool for image encrypting, another for sealed secrets...etc which are tools focused on assets for workloads. However, there is still room for a coco-ctl that should be focused on sysadmins: install/delete the CoCo stack, configure worker nodes for CoCo when needed, monitoring...etc

3. **cc-kbc-client** - This is the new tool that is proposed in the guest components repo. It can get resources but only using the KBS protocol.

There is an open question here. I am not sure if we should continue to support getting resources in the trustee-cli. Getting resources is not required for a client/admin configuring Trustee, but it is useful for testing. We could use the new cc-kbc-client to get resources instead, but only when using the cc-kbc. This would be fine for testing Trustee (we'd have to pull the guest components in the tests, but we could remove the gc dependency in the tools), but it wouldn't work for some of the other KMSes. So if we don't support getting resources in trustee-cli we wouldn't have a way to exercise the offline kbcs other than the CDH. Personally, I think that's fine but it would be a regression.

Getting resources in the trustee-cli is useful for an admin to check the configuration. For example, "Do I have the correct containers policy for signed images in KBS?"