This page describes how customer-managed encryption keys work with Cloud SQL. To use this feature right away, see Using customer-managed encryption keys (CMEK).
Is CMEK right for me?
Customer-managed encryption keys are intended for organizations that have sensitive or regulated data that requires them to manage their own encryption key.
Google-managed encryption versus customer-managed encryption
The CMEK feature lets you use your own cryptographic keys for data at rest in Cloud SQL. After adding customer-managed encryption keys, whenever an API call is made, Cloud SQL uses your key to access data.
Cloud SQL uses Google-managed data encryption keys (DEK) and key encryption keys (KEK) to encrypt Cloud SQL. There are two levels of encryption:
- The DEK encrypts data.
- The KEK encrypts the DEK.
The Cloud SQL instance stores the encrypted DEK alongside the encrypted data on the PD and Google manages the Google KEK. With customer-managed encryption keys, you create a key that wraps the Google KEK. Customer-managed encryption keys let you create, revoke, and delete the KEK.
Customer-managed encryption keys are stored within a managed service called Cloud Key Management Service (Cloud KMS).
The diagrams below show how data-at-rest encryption works inside a Cloud SQL instance when using default Google encryption versus customer-managed encryption keys.
When decrypting data wrapped with customer-managed encryption keys, Cloud SQL uses the KEK to decrypt the DEK and the unencrypted DEK to decrypt data-at-rest.
When does Cloud SQL interact with CMEK keys?
|Instance creation||During instance creation, you configure the instance to use customer- managed encryption keys.|
|Backup creation||During backups for a CMEK-enabled instance, customer-managed encryption keys encrypt user data, such as user queries and responses. Backups from a CMEK-enabled instance inherit its encryption with same Cloud KMS key as the source instance.|
|Instance restore||During restores for a CMEK-enabled instance, Cloud SQL uses the key to access data on the backup instance being restored. When restoring to a different instance, the target instance can use a different key for encryption.|
|Replica creation||Read and failover replicas from a CMEK-enabled instance inherit CMEK encryption with the same Cloud KMS key as the primary instance.|
|Clone creation||Clones from a CMEK-enabled instance inherit CMEK encryption with same Cloud KMS key as the source instance.|
|Instance update||During updates to a CMEK-enabled instance, Cloud SQL checks the CMEK key.|
What locations support CMEK-enabled Cloud SQL instances?
CMEK is available in all Cloud SQL instance locations.
Understanding service accounts
When your Cloud SQL instances have CMEK enabled, you need to use a service account to request key access from Cloud KMS.
To use a customer-managed encryption key on a project, you must have a service account and you must grant the customer-managed encryption key access to the service account. The service account must exist inside of the project. The service account is visible in all regions.
If you use the Console to create an instance, Cloud SQL automatically creates the service account when you first choose the Customer-managed key option (if a service account does not already exist). You don't need to have special permissions on your user account when Cloud SQL automatically creates the service account.
In Cloud KMS, you need to create a keyring with a cryptographic key, set with a location. When you create a new Cloud SQL instance, you select this key to encrypt the instance.
You need to know the key ID and key region when you create new Cloud SQL instances that use customer-managed encryption keys. You must put new Cloud SQL instances in the same region as the customer-managed encryption key associated with the instance. You can create one project for both keys and Cloud SQL instances, or different projects for each.
Customer-managed encryption keys use the following format:
When you disable the key version, Cloud SQL suspends the instances encrypted with that key version. When you re-enable the key version, Cloud SQL resumes the instances encrypted with that key version.
When you rotate keys, instances encrypted with that key are not re-encrypted with the new primary key version.
How do I make CMEK-encrypted data permanently inaccessible?
You might have situations where you want to permanently destroy data encrypted with CMEK. To do this, you destroy the customer-managed encryption key version. You can't destroy the keyring or key, but you can destroy key versions of the key.
How do I export and import data from and to a CMEK-enabled instance?
If you want your data to remain encrypted with a customer-managed key during an export or import, you must set a customer-managed encryption key on the Cloud Storage bucket before exporting data to it. There are no special requirements or restrictions to importing data to a new instance when the data was previously stored on an instance enabled with a customer-managed encryption key.
The following restrictions apply when using customer-managed encryption keys:
- You can't enable customer-managed encryption keys on an existing instance.
- You can't rotate key versions on existing instances.
- You can't assign a different key version to a replica.
- You can't assign a different key version to a clone.
- You can't use customer-managed encryption keys to encrypt:
- External servers (external primary instances and external replicas)
- Instance metadata, such as the instance ID, database version, machine type, flags, backup schedule, etc.
- You can't use customer-managed encryption keys to encrypt user data in transit, such as user queries and responses.
- Learn about encryption at rest in Google Cloud Platform.
- Learn how to create an instance with CMEK enabled.
- Learn about Cloud Key Management Service (Cloud KMS).
- Learn about Quotas for Cloud KMS resources.
- Learn about IAM service accounts.
- Find other products that use CMEK.