Resource Backends

Resource Storage Backend

KBS stores confidential resources through a StorageBackend abstraction specified by a Rust trait. The StorageBackend interface can be implemented for different storage backends like e.g. databases or local file systems.

The KBS config file defines which resource backend KBS will use. The default is the local file system (LocalFs).

Local File System Backend

With the local file system backend default implementation, each resource file maps to a KBS resource URL. The file path to URL conversion scheme is defined below:

The KBS root file system resource path is specified in the KBS config file as well, and the default value is /opt/confidential-containers/kbs/repository.

Aliyun KMS

Alibaba Cloud KMS(a.k.a Aliyun KMS) can also work as the KBS resource storage backend. In this mode, resources will be stored with generic secrets in a KMS instance. One KBS can be configured with a specified KMS instance in repository_config field of KBS launch config. These materials can be found in KMS instance’s AAP. When being accessed, a resource URI of kbs:///repo/type/tag will be translated into the generic secret with name tag. Hinting that repo/type field will be ignored.

Google Cloud Secret Manager

Google Cloud Secret Manager can also work as the KBS resource storage backend. Build the KBS with the gcp feature (e.g. cargo build --features gcp). In the KBS config, add a resource plugin with storage_backend_type = "gcp" and the project_id that owns the secrets. Resources are stored as Secret Manager secrets and fetched via AccessSecretVersion. A resource URI of kbs:///repo/type/tag is translated into the Secret Manager version projects/<project_id>/secrets/<tag>/versions/latest; the repo/type portion is ignored and the latest enabled version is served, matching the behavior of the Aliyun KMS backend. Credentials are resolved via Application Default Credentials (ADC): the GOOGLE_APPLICATION_CREDENTIALS environment variable, gcloud auth application-default login, or the GCE/GKE/Cloud Run metadata server (workload identity). This backend is read-only; writes and deletes return an error, so provision and rotate secrets via GCP APIs. For details, see the resource storage backend documentation in the Trustee repo.

Pkcs11

The Pkcs11 backend uses Pkcs11 to store plaintext resources in an HSM. Pkcs11 is a broad specification supporting many cryptographic operations. Here we make use only of a small subset of these features. Often with Pkcs11 an HSM is used to wrap and unwrap keys or store wrapped keys. Here we do something simpler. Since the KBS expects resources to be in plaintext, we store these resources in the HSM as secret keys of the generic secret type. This storage backend will provision resource to the HSM in the expected way when a user uploads a resource to the KBS. The user must simply specify the location of an initialized HSM slot. Keys can also be provisioned to the HSM separately but they must have the expected attributes.

The Pkcs11 backend is configured with the following values.

• module The module path should point to a binary implementing Pkcs11 for the HSM that you want to use. For example, if you are using SoftHSM, you might set the module path to /usr/local/lib/softhsm/libsofthsm2.so.
• slot_index The slot index points to the slot in your HSM where the secrets will be stored. The slot must be initialized before starting the KBS. No slot_index is set, the first slot will be used.
• pin The user password for authenticating a session with the above slot.

HashiCorp Vault / OpenBao KV

The KBS can use HashiCorp Vault or OpenBao KV v1 as a resource backend, storing and retrieving secrets from a Vault or OpenBao instance. Build the KBS with the vault feature (e.g. cargo build --features vault). In the KBS config, add a resource plugin of type Vault with vault_url, token, and optionally mount_path, verify_ssl, and ca_certs. Resource URIs map to Vault paths as {repository_name}/{resource_type}/{resource_tag}; the secret value is stored under the key data. Only token authentication and KV v1 are supported. For setup, policy examples, and TLS options, see the Vault KV backend documentation in the Trustee repo.