Skip to content

CONCEPT Cited by 1 source

Customer-Managed Keys (CMK)

Customer-Managed Keys (CMK) is the encryption-key ownership model where the customer (the data-owning organisation) controls the root-of-trust key in their own cloud KMS — AWS KMS, Azure Key Vault, Google Cloud KMS — and the SaaS vendor consuming the customer's data only ever receives wrapped (encrypted) derivatives of that key, never the plaintext root.

It sits at the root of an concepts/envelope-encryption hierarchy and is the mechanism behind every "data sovereignty" / "bring-your-own-key" / "hold-your-own-key" regulatory talking point.

The contract

  • Root key lives in customer tenancy. AWS IAM / Azure RBAC / GCP IAM gates access to the key. The vendor is granted a Wrap/Unwrap role or service principal; that is the sum of its authority.
  • Vendor never sees plaintext root key. All vendor-side key material is either a wrapped KEK, a wrapped DEK, or a transient unwrapped DEK used for a bounded scope.
  • Every wrap/unwrap is logged in the customer's audit surface. CloudTrail, Azure Monitor, Google Cloud Audit Logs — the customer sees every time the vendor asked to decrypt something. This is the point: attestation never crosses the trust boundary.
  • Revocation is a unilateral customer action. Removing the vendor's IAM role / disabling the key / rotating it without re-authorising the vendor makes unwrap fail, which makes every downstream wrapped DEK useless. See concepts/cryptographic-shredding.

Why it exists

Shared-responsibility encryption in the cloud historically looked like: the vendor encrypts at rest with vendor-managed keys, the customer trusts the vendor's internal controls. For many enterprises this fails one or more of:

  • Regulatory compliance — finance / healthcare / government frameworks often require the data owner to hold the root of trust, not the processor.
  • Vendor breach isolation — if the vendor is compromised, the customer's ciphertext is still opaque without the customer-held root key.
  • Cross-cloud / cross-tenant auditability — attestation of who decrypted what lives in the customer's log pipeline, not the vendor's.
  • Right-to-be-forgotten at the crypto layer — a GDPR / HIPAA delete can be satisfied by cryptographic shredding of the CMK, without relying on the vendor's physical-delete SLA.

Implementation shape (from Lakebase)

Databricks' Lakebase CMK launch is a clean reference shape:

  1. Account Admin creates a Key Configuration in the vendor's account console — (key identifier: ARN for AWS KMS, Key Vault URL for Azure, Key ID for GCP) + (IAM role / service principal the vendor assumes for Wrap/Unwrap).
  2. Workspace binding — the key config is mapped to a specific workspace. New projects in that workspace inherit the CMK; different workspaces can use different CMKs.
  3. Vendor-internal envelope — the customer's CMK wraps a vendor-held KEK, which wraps many DEKs. The CMK is contacted only to unwrap KEKs. DEKs are per data segment. See concepts/envelope-encryption.
  4. Rotation — rotating the CMK at the KMS is seamless; the vendor re-wraps its KEK/DEK set, no data is re-encrypted, no downtime.
  5. Revocation — revoking the vendor's role (or deleting the key version) cryptographically shreds the data. (Source: sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres)

Separation of duties

The Account ↔ Workspace split encodes classic separation of duties: security admins manage keys without needing data access; data users operate on data without key-management authority. The CMK is the boundary.

Caveats

  • CMK is not a silver bullet. You still trust the vendor's Wrap / Unwrap code path with unwrapped DEKs (briefly) and with the KEK. Side-channel, memory-dump, or malicious-insider attacks at the vendor still matter.
  • KMS is an availability dependency. If the customer's KMS is unreachable, the vendor cannot unwrap new DEKs and data becomes read-unavailable for new segments / cold caches. Usually mitigated by short-lived KEK caches at the vendor side and KMS-region redundancy.
  • Rotation cadence is a customer choice. "Seamless rotation" doesn't specify how often you should rotate; that's a compliance and threat-model decision.
  • CMK binding granularity varies. Lakebase binds at the workspace level; per-project / per-table CMK is not described in the launch post. Some vendors expose finer-grained key scopes.

Seen in

Last updated · 200 distilled / 1,178 read