Skip to main content

POST /admin/tenant-kms

Onboard a customer KMS provider. KnoxCall performs a live wrap + unwrap round-trip on a 32-byte test payload before committing — if the IAM/RBAC grant isn’t working, the request fails immediately and nothing is stored. Calling this endpoint when a KMS configuration already exists replaces it (UPSERT). The probe runs first; if it fails, the existing config is unchanged. Auth: Session JWT (Authorization: Bearer <session-token>) plus the X-Tenant-ID header, and the caller must have the owner or admin role. Requests missing X-Tenant-ID are rejected with 400 X-Tenant-ID header required. No step-up required.

Request body

provideraws | gcp | azure kms_key_ref — The provider-specific key identifier:
  • AWS: full key ARN (arn:aws:kms:REGION:ACCOUNT:key/KEY-ID or .../alias/ALIAS)
  • GCP: full resource path (projects/P/locations/L/keyRings/R/cryptoKeys/K)
  • Azure: vault key URL (https://VAULT.vault.azure.net/keys/KEY-NAME)
config — Provider-specific authentication references. Static long-lived credentials (access keys, service account JSON, client secrets) are rejected at the API level.

Response

rewrap_status is always "enqueued" — KnoxCall unconditionally issues a background rewrap lease after onboarding.