Add basic Trustee plugin support to guest-components

[fitzthum]

Following from #1208 and confidential-containers/trustee#1158, let's make the handling of trustee plugins/endpoints in the guest-components.

Specifically, add a plugin parameter to get_resource. Use this to create the request to Trustee. This way it is explicit which plugin we are using.

Also, add support for plugins to the trustee-attester. Add an optional plugin argument that can specify a plugin.

This PR does not change the behavior of the CDH. Instead, we hardcode the CDH to always use the resource plugin. Again, this is much more explicit than what we do now. In the future we can extend the CDH to support other plugins via sealed-secret, ASR, and other interfaces.

[Xynnn007]

As I once comment: I prefer a form that the plugin name is contained inside the URI, than another separate parameter.

This requires that the existing URI format remain valid; they are all resources. Note that when I designed KBS URI, I put a KBS host/port field in the URI.

However, as we used it more, we gradually realized that the actual KBS connection was defined by a global configuration file, such as the CDH configuration file. Therefore, it's completely unnecessary to include this field in the URI. So I suggest updating the KBS URI document, replacing the host/port part with "plugin," and leaving it blank by default as "resource."

This ensures backward compatibility, while also simplifying user experience and code design, avoiding the use of multiple parameters.

This design style also exists in Alibaba Cloud OSS object storage—a global configuration file specifies the OSS address, and the OSS URI (oss://x/x/x) includes both the bucket and the path.

[mythi]

Not sure what is the best place to add comments. One consideration I see is if we want plugins to define their own versioning instead of kbs/v0

[fitzthum]

However, as we used it more, we gradually realized that the actual KBS connection was defined by a global configuration file, such as the CDH configuration file. Therefore, it's completely unnecessary to include this field in the URI. So I suggest updating the KBS URI document, replacing the host/port part with "plugin," and leaving it blank by default as "resource."

I am open to this. I have thought about adding support for multiple KBSes. There is a chance we will want to do that at some point, but I am ok with sacrificing that parameter for plugins. The backwards compatibility part is very important. We can't update all the URIs that are already out there.

[Xynnn007]

Not sure what is the best place to add comments. One consideration I see is if we want plugins to define their own versioning instead of kbs/v0

This is a good question. A question from my side is what does v0 mean to us and will it change in future? If yes, we might need to consider include the version number and how default it will be in the URI.

I am open to this. I have thought about adding support for multiple KBSes. There is a chance we will want to do that at some point, but I am ok with sacrificing that parameter for plugins.

There will be a trade-off for URI and multiple KBSes. My idea is that for most people, there's only one KBS instance, and the URI doesn't need to be considered. However, for the few who need multiple KBS configurations, we can recommend using one-shot CDH tool directly?

The backwards compatibility part is very important. We can't update all the URIs that are already out there.

Actually in the code all the origin of address of the trustee is from AA_KBC_PARAMS env than the URI itself, so the design of kbs address in the URI has not been used since it is define. I suspect that nobody cares or notices this before. So it might be ok to do the change, but we also need to make the change public in community meeting if we decide to do.

[fitzthum]

This is a good question. A question from my side is what does v0 mean to us and will it change in future? If yes, we might need to consider include the version number and how default it will be in the URI.

I think we probably don't want plugins to have their own versions. Really we need to formalize a backwards compatibility strategy in Trustee. We don't really use this version field at all today.

Actually in the code all the origin of address of the trustee is from AA_KBC_PARAMS env than the URI itself, so the design of kbs address in the URI has not been used since it is define. I suspect that nobody cares or notices this before. So it might be ok to do the change, but we also need to make the change public in community meeting if we decide to do.

Yeah I mean that I like this proposal because it doesn't break the URIs we already have (which don't use a plugin and don't use the first field for anything). I think it is probably a good idea to switch the first field to be a plugin.