About customer-managed encryption keys (CMEK)

This page describes how customer-managed encryption keys (CMEK) work with Memorystore for Redis. 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 Memorystore for Redis. After adding customer-managed encryption keys, whenever an API call is made, Memorystore uses your key to access data.

Memorystore uses Google-managed data encryption keys (DEK) and key encryption keys (KEK) to encrypt Memorystore for Redis. There are two levels of encryption:

The DEK encrypts data.
The KEK encrypts the DEK.

The Memorystore 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 managed through the Cloud Key Management Service API.

The diagrams below show how data-at-rest encryption works inside a Memorystore 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, Memorystore 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 Memorystore interact with CMEK keys?

Operation	Description
Instance creation	During instance creation you configure the instance to use customer-managed encryption keys.
Instance update	Memorystore checks the CMEK key during updates to a CMEK-enabled instance.

What data is encrypted using CMEK?

CMEK encrypts the following types of data:

Customer data stored in persistent storage.
Metadata related to security features like AUTH and in-transit encryption.

About service accounts

When creating an instance with CMEK you must grant the cloudkms.cryptoKeyEncrypterDecrypter role to the Memorystore service account that has the following format:

service-[PROJECT_NUMBER]@cloud-redis.iam.gserviceaccount.com

Granting this permission allows the service account to request key access from Cloud KMS.

For instructions on granting this permission to the service account, see Granting the service account access to the key.

About keys

In Cloud KMS, you need to create a keyring with a cryptographic key that uses a symmetric encryption/decryption algorithm. When you create a new Memorystore instance, you select this key to encrypt the instance. You can create one project for both keys and Memorystore instances, or different projects for each of them.

CMEK is available in all Memorystore instance locations. The key and keyring region must be set to the same region as the Memorystore for Redis instance. A multi-region or global region key does not work. A request for creating a Memorystore instance fails if the regions don't match.

CMEK for Memorystore is compatible with Cloud External Key Manager (Cloud EKM).

Customer-managed encryption keys use the following format:

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

If Memorystore is unable to access any key version currently being used (such as if you disable the key version), Memorystore shuts down the instance without undue delay. In the Google Cloud console, a suspended instance shows a red exclamation mark tooltip on the Instances page. When hovering over the tooltip, "No state" is displayed. Once the key becomes accessible again, Memorystore automatically resumes the instance.

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 import or export, 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 for importing data to a new Memorystore instance when the data was previously stored on a CMEK-enabled Memorystore instance.

Behavior of destroying/disabling a CMEK key version

If you wish to ensure no data access to your instance, you can do so by disabling the primary key version of your customer-managed encryption key. Doing so shuts down your instance without undue delay. In addition Memorystore shuts down an instance without undue delay if any in-use customer managed encryption key is disabled/destroyed. This includes any older key version still being used by a Memorystore instance. You can use either gcloud or the Google Cloud console to see if your instance is suspended:

For the Google Cloud console, if your instance is suspended you see a red tooltip notification next to your instance in the Memorystore for Redis Instances page. The tooltip displays "No state" when your cursor hovers over it.

For gcloud, if you run gcloud beta redis instances describe, and you do not see state: READY, state: REPAIRING, or any other state in the instance metadata, this means your instance is suspended.

Reenabling/restoring an in-use CMEK key version

An instance is unhidden after reenabling/restoring an in-use CMEK key version.

Restrictions

The following restrictions apply when using customer-managed encryption keys with Memorystore:

You can't enable customer-managed encryption keys on an existing Memorystore instance.
The region for the key, keyring, and Memorystore instance must all be the same.
You must use the symmetric encryption/decryption algorithm for your key.
Cloud KMS encryption and decryption rates are subject to a quota.

CMEK organization policies

Memorystore for Redis supports organization policy constraints that can be used for CMEK protection.

Policies can limit which Cloud KMS keys can be used for CMEK protection.

When the Memorystore for Redis API is in the Deny policy list of services under the constraint constraints/gcp.restrictNonCmekServices, Memorystore for Redis creation fails for non-CMEK-protected instances.
When constraints/gcp.restrictCmekCryptoKeyProjects is configured, Memorystore for Redis creates CMEK-protected instances that are encrypted using a key from an allowed project, folder, or organization.

For more about configuring CMEK organization policies, see CMEK organization policies.