CockroachDB Dedicated and CockroachDB Serverless — CockroachDB’s fully managed DBaaS offerings — allows global organizations to focus on building groundbreaking applications and let the database handle their transactional data at required scale, with high availability and multi region disaster proofing capability. These customers trust CockroachDB to store their data in a secure manner with guardrails similar to what they would implement in their own infrastructure.
But what if we could provide customers with an additional level of control over how their data is protected (and without the need to trust a bunch of governance policies and controls on our end)?
Now we can. Customer-Managed Encryption Keys (CMEK) allow CockroachDB managed services customers to bring their own key from AWS KMS or GCP Cloud Key Management, using a multi-key hierarchical encryption method to encrypt the cluster data and manage backups.
Why we built CMEK encryption
When customer application teams consider using a DBaaS like CockroachDB to store and manage their data (which could also include sensitive data), a lot of due diligence is required. The org’s architecture, security and legal teams must all consult on potential risk assessment and mitigation processes. This extensive investigation is understandable since the data would be managed outside the customer’s own infrastructure and guarded premises — meaning they must fully trust the service provider’s processes and controls. Questions that naturally arise include:
Do we have any control over how the data is managed by the service provider?
If the service provider takes any backups of the data, how are those protected?
Is there a way to somehow disable all access to the data when investigating any organization-wide security incidents?
What sort of guardrails exist to prevent access to the data by the service provider support team or by the employees of cloud providers who manage the underlying infrastructure (AWS, GCP)?
CMEK encryption addresses the core of each of those concerns.
How does CMEK encryption work?
CockroachDB can access a symmetric key provided by the customer from their cloud account (AWS or GCP), using a cross-tenant IAM role or service account (again managed by the customer), and use that key to encrypt or decrypt the data on the cluster and managed backups utilizing a multi-key hierarchical encryption method. For the cluster data:
The key in question is referred to as CMEK, and internally it’s used to encrypt a key encryption key (KEK) which is unique per CockroachDB cluster region (which means there are multiple KEKs in a multi-region cluster).
The KEK is used to encrypt the data encryption key (DEK) which is unique per CockroachDB cluster node (which means there are multiple DEKs in a multi-node cluster).
The DEK is used to encrypt the data files stored on the cluster disks (EBS volumes on AWS, and Persistent Disks on GCP).
The DEK is rotated periodically, and customers can rotate the CMEK as well as per their enterprise governance policies. On top of this, customers can revoke CockroachDB access to their managed key and invoke a revoke API, thereby disabling the cluster for all kinds of reads, writes & administrative operations.
Through the same mechanism, for managed cluster backups that are stored on cloud-native storage (S3 in AWS, Cloud Storage in GCP) in CockroachDB, the CMEK is used to encrypt a backup encryption key (BEK), which is unique per cluster and is in turn used to encrypt the backup files. A different BEK is used for every full backup.
For multi-region clusters, customers have the flexibility to configure the same CMEK for all regions, or use a different CMEK per-region. AWS customers can also use the multi-region keys in AWS KMS, and GCP customers can also use the multi-region keys in GCP’s Cloud Key Management.
Now looking back at the concerns from earlier, CMEK encryption provides strong measures to address all of those, by providing a level of control to the customers by allowing them to manage the root key for encryption of their cluster data and managed backups, encrypting at a file-level rather than just at the infrastructure level, and by providing mechanisms to rotate & revoke access to their keys. Check out our FAQ for more information.
How does CockroachDB access the CMEK?
CockroachDB uses respective cloud-native IAM capabilities to access the CMEK provided by the customer.
In AWS, we use a cross-account IAM role (managed by the customer) to access the CMEK in the customer’s KMS instance. Customer provides the encryption & decryption IAM permissions on the CMEK to a IAM role in their AWS account, and configures a trust relationship with the CockroachDB AWS account of their cluster to assume the above IAM role. In addition, we also ask the customers to configure their CockroachDB Cloud Organization Id as the External Id in the cross-account trust relationship to address the confused deputy problem.
In GCP, we use the cross-tenant service account delegation mechanism to access the CMEK in the customer’s Cloud Key Management instance. Customer provides the encryption & decryption IAM permissions on the CMEK to a service account in their GCP project, and then allows the CockroachDB service account of their cluster to create tokens for their cross-tenant service account.
How to get started
If you don’t have your own CockroachDB cluster yet, the first step is to create one by following these instructions. Once the cluster is set up, you could use this tutorial to enable CMEK for your cluster. All you need are a CMEK key and a cross-tenant IAM role or service account in your cloud account.
If you use Hashicorp Vault to manage keys in your cloud infrastructure, you could do that too as part of our partner-validated solution.
