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 customer-managed encryption keys 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 Key Management Service (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 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 KMS key as the master instance.|
|Clone creation||Clones from a CMEK-enabled instance inherit CMEK encryption with same 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 kms_name_short.
To use a customer-managed encryption key on a project, you must create a service account and grant the customer-managed encryption key access to the service account. You create the service account inside of the project. The service account is visible in all regions.
In 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 cannot destroy the keyring or key, but you can destroy key versions of the key.
How do I import data exported from a CMEK-enabled instance?
There are no special requirements or restrictions to importing data to a new instance, when the data was previously stored on a CMEK-enabled instance.
The following restrictions apply when using customer-managed encryption keys:
- You cannot rotate key versions on existing instances.
- You cannot assign a different key version to a replica.
- You cannot assign a different key version to a clone.
You cannot use customer-managed encryption keys to encrypt:
- External servers (external master instances and external replicas)
- Instance metadata, such as the instance ID, database version, machine type, flags, backup schedule, etc.
- MySQL First Generation instances
You cannot use customer-managed encryption keys to encrypt user data in transit, such as user queries and responses.