Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 0 additions & 36 deletions attestation-agent/docs/KBS_URI.md

This file was deleted.

76 changes: 76 additions & 0 deletions attestation-agent/docs/RESOURCE_URI.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# Resource URIs

## Introduction

Resource URIs are used across Confidential Containers to identify resources.
For example, the metadata of an encrypted image can contain a resource URI
referencing the image decryption key.
An image signature policy or a sealed secret can contain a resource URI.

Although these have been referred to as KBS Resource URIs, this abstraction
is implemented by the CDH.

The resource URI is not the same thing as the path for requesting a resource
from Trustee's REST API. The mapping between these is described below.

Technically, the Resource URI is not tied to any specific KBS, but this document
mainly focuses on Trustee and the CC_KBC and describes how the resource URI
relates to Trustee.
Some legacy code, such as the SEV KBC or the FS KBC may fulfill resource URIs
in different ways.

## Specification

A Resource URI must comply with the following format:

```plaintext
kbs+<plugin>://<kbs_host>:<kbs_port>/<repository>/<type>/<tag>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this design

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The asymmetry here is that with kbs+<plugin>:// callers need to know the resource is provided by <plugin> but with the resource plugin, they have no way to say the resources comes from vault.

How the plugin URIs can be supported with api-server-rest queries?

Copy link
Copy Markdown
Member

@Xynnn007 Xynnn007 May 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vault is not a plugin level conception, but a resource plugin level. Thus it's expected that the caller does not know that.

for ASR, currently is 127.0.0.1:8006/cdh/resource/.... we could generize it as 127.0.0.1:8006/cdh/<plugin-in-name>/... for kbs+<plugin-in-name>:///...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also that the caller doesn't get to request a concrete backing store for their resource is (say, vault or filesystem), this is up to the KBS, no?

I also like this URI scheme 👍

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vault is not a plugin level conception, but a resource plugin level.

yup, my comment was just that the implementation detail is visible to the user and they don't necessarily understand: why kbs+pcks11:// is needed but kbs+vault:// is not.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the pkcs11 apis are different from the vaults. see https://github.com/confidential-containers/trustee/blob/main/kbs/src/plugins/implementations/pkcs11.rs#L135 for example wrap-key

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, also worth noting that the resource plugin only supports one storage backend anyway.

```

### Scheme

The scheme always begins with `kbs`. Typically the scheme is simply `kbs://`, but a plus sign
can be used to specify that the resource should be fulfilled by a particular plugin.

For instance, to represent a resource fulfilled by the Trustee `pkcs11` plugin, the
scheme would be `kbs+pkcs11://`.

If no plugin is specified, the CDH will request a resource from the `resource` plugin.

### Host and Port

The host and port point to the KBS instance that will serve the resource.
Today, the CDH ignores these fields and instead gets the KBS URI and port
from the CDH config file.
This way, the resource URI does not need to be updated if the KBS URI changes.
This means that generally only one KBS serves resources for a pod, there are ways
to work around this with sealed secrets.
Multi-KBS workloads may be supported in the future.

Since these fields are ignored, most resource URIs leave them out.
This results in three slashes in a row.
For example, `kbs:///repository/type/tag`.

### Repository, Type, and Tag

Currently resource URIs have three levels of identifiers/scope.
The terms `repository`, `type`, and `tag` are somewhat arbitrary.
These identifiers can be used in any way.
Comment on lines +54 to +58
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's resource plugin-specific and no requirements on other plugins

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I was also thinking whether it is a good idea to require the same path segment for every plugin, for some this hierarchy might just not make any sense. but it keeps implementation complexity at bay for now and that requirement can be relaxed later once it becomes a nuisance

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - and there is already some implementations that do not follow this, e.g. pkcs11

Copy link
Copy Markdown
Member Author

@fitzthum fitzthum May 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we need to clarify this. Currently you cannot access the pkcs11 plugin via the resource uri, which is essentially a bug imo. I am open to allowing arbitrary length requests, like we do with rv uris, but that is not how the resource uri works today.


### Query Strings

The resource URI also supports query strings.

## Examples

* `kbs://example.cckbs.org:8081/alice/decryption-key/1`
* `kbs:///a/b/c`
* `kbs+pkcs11:///a/b/c`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw the original resource URI could also support query string, like kbs+plugin1://a/b/c?d=e


## Mapping

The resource URI is transformed into an HTTP(S) request.
Specifically, the request will be made to `http://<kbs_host>:<kbs_port>/kbs/v0/<plugin>/alice/decryption-key/1`.

If no plugin is specified in the resource URI, `resource` will be used.
More information on the KBS API can be found [here](https://github.com/confidential-containers/trustee/blob/main/kbs/docs/kbs.yaml).
Loading