Support broking confidential resources which image-rs needs.

[jialez0]

This generic KBS will replace simple-kbs and verdictd as the default recommended component of the CoCo solution, so it needs to support providing existing secret resources. Currently, in the confidential containers architecture, the component requesting resources from KBS through the Attestation Agent is image-rs, so our generic KBS needs to support the provision of the following kinds of resources required by image-rs:

1. Container image decryption key.
2. Registry pulling policy file.
3. Container image signature verification key, including cosign and simple signing.
4. Registry authentication informations.

This work is based on #16.

[Xynnn007]

I wonder whether we have or will have an API which can be used to "registry" a resource in the KBS? Here "registry" means

• Allocate repository, type and tag for a new resource (as https://github.com/confidential-containers/kbs/blob/main/docs/kbs.yaml#L74)

If so, maybe we can flexibly add new resources in need for test and for production

[fitzthum]

I think it's still an open question how exactly we should handle client resources. There is a huge range of options. We could do something really simple where every resource is just an opaque blob with an ID. On the other hand we could have the KBS automatically generate certain resources (such as signature policy files) based on which workload is running. I think we probably should have some kind of workload-level abstraction (i.e. a workload ID), but I'm not sure what is optimal. Looking forward to discussing with everyone.

I think a lot of @Xynnn007's issues like confidential-containers/guest-components#50 are somewhat connected to this.

[Xynnn007]

Hi @fitzthum , to deal with this, we've proposed a scheme here confidential-containers/documentation#85. I think this scheme can be fit with permission control and authentication design for KBS

[Xynnn007]

This issue could be covered by #25

[jialez0]

Now cc-kbc of AA and KBS can support broking resources described in this issue, so this issue can be closed now.

As for how exactly we should handle client resources, we can discuss the improvement in detail in a new issue in the future.