pkcs11 plugin can no longer provider KBS resources

[berrange]

Describe the bug

In #735 (CC @tylerfanelli) the pkcs11 resource backend was turned into a standalone plugin, in order to provide new functionality for wrapping/unwrapping data with a protected key, in parallel with the existing resource data storage facility.

The PR describe indicates backwards compatibility was intended

The resource storage backend functionality is preserved, storing and retrieving secrets were originally done by setting the storage backend in the resource plugin to be PKCS11. With this plugin, the original resource URL to store/fetch secrets:

/kbs/v0/resource/{REPOSITORY}/{TYPE}/{TAG}

can be replaced by:

/kbs/v0/pkcs11/resource/{REPOSITORY}/{TYPE}/{TAG}

and the behavior will remain the same.

but I'm not seeing how backwards compatibility is actually achieved in practice, because this requires every trustee client to be modified to know to use a different URL path, and that has not been done.

The 'trustee-attestor' binary for example, only knows how to handle /kbs/v0/resource paths:

https://github.com/confidential-containers/guest-components/blob/main/attestation-agent/kbs_protocol/src/client/rcar_client.rs

        let mut remote_url = format!(
            "{}/{KBS_PREFIX}/resource/{}/{}/{}",
            self.kbs_host_url, resource_uri.repository, resource_uri.r#type, resource_uri.tag
        );

While it would be possible to modify the client code to support choice of the different /kbs/v0/pkcs11/resource prefix this feel undesirable. The choice of resource storage backend used by the KBS ought to be kept completely opaque to the guest OS, so the owner of the KBS can change it at will, without any effect on guest attestation.

IOW, while the idea of supporting key wrapping via PKCS11 is fine, it feels like the existing PKCS11 resource datra storage backend should have been left untouched, and a new PKCS11 plugin added solely for the key wrapping features.

How to reproduce

• Configure the KBS with the pkcs11 plugin
• Attempt to use it with trustee-attestor to acquire data

CoCo version information

0.13.0 or later

What TEE are you seeing the problem on

None

Failing command and relevant log output

[fitzthum]

This is related to confidential-containers/guest-components#1208, which unfortunately has stalled. Our clients do not currently have support for plugins. There was some discussion about whether to use the resource URI to identify the plugin, but I think the consensus was to add a new argument to our clients allowing users to specify a plugin other than the resource backend. This has not been implemented yet. It wouldn't be too hard to add to the trustee attester.

While it would be possible to modify the client code to support choice of the different /kbs/v0/pkcs11/resource prefix this feel undesirable. The choice of resource storage backend used by the KBS ought to be kept completely opaque to the guest OS, so the owner of the KBS can change it at will, without any effect on guest attestation.

The resource backend should be opaque to the client, but which plugin to use is something that a user would select. You have an interesting point about having both a resource backend and a plugin for PKCS11.

[berrange]

While it would be possible to modify the client code to support choice of the different /kbs/v0/pkcs11/resource prefix this feel undesirable. The choice of resource storage backend used by the KBS ought to be kept completely opaque to the guest OS, so the owner of the KBS can change it at will, without any effect on guest attestation.

The resource backend should be opaque to the client, but which plugin to use is something that a user would select. You have an interesting point about having both a resource backend and a plugin for PKCS11.

Yes, the client plugin would be neccessary for enabling the key data wrapping feature of the PKCS11 plugin, but shouldn't be required for the previously existing resources data feature.

[fitzthum]

I wouldn't be against re-introducing a resource backend. One thing to consider is that we can only have one resource backend at a time. I'm not sure if people would want to serve all of their resources via PKCS11 or just a subset.

[berrange]

I wouldn't be against re-introducing a resource backend. One thing to consider is that we can only have one resource backend at a time. I'm not sure if people would want to serve all of their resources via PKCS11 or just a subset.

With my OS vendor hat on, serving resources via the PCKS11 backend is probably the only viable (in-tree) option we could use currently, assuming its paired with a suitably secure HSM (or soft-HSM impl). The local FS option isn't encrypted so that's out except for dev scenarios, the Alibaba KMS is a commercial service, and Vault is under the BUSL so undesirable to attempt to support. In theory someone could write a partitioning resource backend, that delegated different subsets of data paths to multiple other resource backends.

[fitzthum]

Well part of your problem can be resolved via confidential-containers/guest-components#1293

[berrange]

and Vault is under the BUSL so undesirable to attempt to support

Not quite accurate, as I wasn't aware Vault was forked to create the OpenBao project under a full open license

[fitzthum]

(there is some discussion about the best way to handle the plugin in the resource URI. this happened last time too. hopefully it will be resolved soonish and we will merge a fix. for now you can just take the changes above if you need them).