About 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 keys.

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:

  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, including software, hardware, and external keys, are all managed through the Cloud Key Management Service API.

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 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 When you create a read or failover replica of a Cloud SQL instance in the same region, it inherits the CMEK from the parent instance. If you create a read or failover replica in a different region, you must select a CMEK from the other region. Each region uses its own set of keys.
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.

About 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.

About keys

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:

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

If Cloud SQL is unable to access the key (such as if you disable the key version), Cloud SQL suspends the instance. Once the key becomes accessible again, Cloud SQL automatically resumes the instance.

When you rotate keys, instances that are encrypted with that key aren't automatically re-encrypted with the new primary key version. You can re-encrypt any existing CMEK primary instance or replica with the new primary key version. For more information about how to re-encrypt a Cloud SQL instance or replica after a key rotation, see Re-encrypt an existing CMEK-enabled instance or replica.

External key managers

You can use keys stored in external key managers, such as Fortanix, Ionic, or Thales, as your customer-managed encryption keys. To learn how to use external keys with Cloud KMS, see Cloud External Key Manager (Cloud EKM).

Key Access Justifications

You can use Key Access Justifications (KAJ) as part of Cloud EKM. KAJ enables you to view the reason for each Cloud EKM request. Additionally, based on the justification provided, you can automatically approve or deny a request. To learn more, see the Overview.

Thus, KAJ provides extra control over your data by providing a justification for each attempt to decrypt the data.

For related information about using your keys with Cloud SQL instances, see Creating a Cloud SQL instance with CMEK.

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.

Restrictions

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 assign a different key to a replica in the same region as the primary instance. For cross-region replicas, you need to create a new key for the replica region.
  • You can't assign a different key 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.

What's next