Qeet Docs
Platform

Secrets vault

Per-tenant AES-256-GCM secret storage, with the encryption key sourced via a pluggable KeyProvider (AWS KMS drops in).

Qeet ID includes a per-tenant secrets vault: store sensitive values (provider credentials, signing material, integration secrets) encrypted with AES-256-GCM. The encryption key is sourced through a KeyProvider abstraction — decoupled from the JWT secret — so the underlying key management is swappable.

Store & retrieve

GET/v1/tenants/{tenantID}/secretsList secrets (metadata only)
POST/v1/tenants/{tenantID}/secretsCreate a secret
DELETE/v1/tenants/{tenantID}/secrets/{id}Delete a secret
POST/v1/tenants/{tenantID}/secrets/{id}/revealReveal a secret value

Listing returns metadata only; the plaintext value is returned solely by the explicit reveal endpoint, which is audited.

Reveal is sensitive

Every reveal is recorded in the audit log. Treat reveal as a break-glass operation, not a routine read path.

KeyProvider & BYOK

The vault key comes from a KeyProvider interface. The default is local key material; an AWS KMS provider drops into the same interface for BYOK / envelope encryption — you supply a real KMS key. The same abstraction backs JWT/OIDC signing key material.

KMS-backed keys are an external dependency (you provide the cloud key), not a code gap — the interface is in place and the AWS KMS provider plugs in. See the deployment runbook.

On this page