Overview of customer-managed encryption keys (CMEK)

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:

  1. The DEK encrypts data.
  2. 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.

Without CMEK

Data is uploaded to Google, then chunked and each chunk is encrypted with its own data encryption key. Data Encryption keys are wrapped using a key encryption key. With default Google Encryption, the key encryption key is retrieved from Google's internal Keystore. Encrypted chunks and wrapped encryption keys are distributed across Google's storage infrastructure.

With CMEK

Data is uploaded to Google, then chunked and each chunk is encrypted with its own data encryption key. Data Encryption keys are wrapped using a key encryption key. With CMEK using Cloud KMS, the key encryption key is retrieved from Cloud KMS. Encrypted chunks and wrapped encryption keys are distributed across Google's storage infrastructure.

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.

Data chunk encrypted with DEK and stored with wrapped DEK. A request to unwrap the DEK is sent to KMS storage, which stores the unexportable KEK. KMS Storage returns the unwrapped DEK.

When does Cloud SQL interact with CMEK keys?

Operation Notes
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.

Understanding keys

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:

projects/[CMEK_ENABLED_PROJECT]/locations/[REGION]/keyRings/[RING_NAME]/cryptoKeys/[KEYNAME]

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.

Restrictions

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.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud SQL for MySQL
Need help? Visit our support page.