Engine selection

Vault paths include an engines/{engine} segment. The selector tells Vault which engine owns a request and lets responses identify the engine that owns each resource.

Concrete engine selector

Use a configured engine name, such as qibdo, whenever a request changes state. For example:

POST /vault/v1/workspaces/{workspace}/engines/qibdo/secrets HTTP/1.1

Create, update, delete, revoke, rotate, and cryptographic operations require a concrete engine. The selector prevents a mutation from being broadcast to more than one provider.

Federated reads

Supported get and list requests accept - as the federation selector:

GET /vault/v1/workspaces/{workspace}/engines/-/secrets HTTP/1.1

Vault combines the resources visible through the configured engines and includes an engine field on every returned resource. Use that field when you need to follow up with a concrete request for one result.

- is not a default engine and it never means “use qibdo”. It is a read-only federation selector. Invalid selectors are rejected, and a recognised engine without an implementation returns an explicit unsupported-operation response.

Nested resources

Versions, certificates, and certificate templates keep their parent scope. A federated read can only return children of the parent selected by the request; it does not combine children from unrelated parents. The returned engine identifies the owning provider for each child.

Data location

The selector chooses the engine that stores or operates on sensitive material. The Vault control plane stores resource metadata and audit information. An engine may use its own account, subscription, or project configuration internally; that provider-specific configuration is not part of the public resource path.