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
provider — aws | gcp | azure
kms_key_ref — The provider-specific key identifier:
- AWS: full key ARN (
arn:aws:kms:REGION:ACCOUNT:key/KEY-IDor.../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.