Loading…
Take Control: Customer-Managed Keys for Lakebase Postgres
Ben Hagan
- Source
- Databricks
- Published
- Added to Yomu
Summary
Lakebase Customer Managed Keys (CMK) gives regulated enterprises control of the root of trust through customer-owned keys from AWS KMS, Azure Key Vault, or Google Cloud KMS. Because Lakebase separates persistent storage from elastic Postgres compute that can scale to zero, CMK protects both layers and their caches rather than storage alone. Its hierarchical envelope-encryption model uses the CMK as the root, transient Key Encryption Keys (KEKs) to wrap Data Encryption Keys (DEKs), and unique DEKs for each data segment, while plaintext CMKs remain in the customer’s KMS. Account Admins bind a configured key to a workspace, after which new projects inherit the CMK; rotation needs no re-encryption or downtime, revocation terminates compute instances, and audit services record cryptographic operations.
Context
Enterprises in highly regulated environments need control of the root of trust and cryptographic operations for data throughout the Lakebase lifecycle. Lakebase’s separate storage and compute layers, including their caches and ephemeral data, require encryption beyond conventional storage-only database protection.
Approach / What changed
Lakebase uses customer keys from AWS KMS, Azure Key Vault, or Google Cloud KMS within a hierarchical envelope-encryption model. Databricks uses transient Key Encryption Keys to wrap Data Encryption Keys, while per-boot keys protect ephemeral compute data. Account Admins configure and bind a key configuration to a workspace; revocation terminates compute instances, and CMK rotation avoids data re-encryption or downtime.
Takeaways
- The CMK remains in the customer’s cloud KMS; Lakebase receives wrapped keys and uses the KMS for unwrapping rather than encrypting every data block.
- CMK protection covers persistent data, Safekeeper WAL segments, compute caches, temporary files, and other ephemeral data across Lakebase’s storage and compute layers.
- Revoking the CMK causes key unwrapping to fail and terminates ephemeral compute instances, while cloud-provider audit services log cryptographic operations.