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.
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.
When does Memorystore interact with CMEK keys?
|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:
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.
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 does not currently support Cloud External Key Manager (Cloud EKM).
Customer-managed encryption keys use the following format:
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 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 console to see if your instance is suspended:
For the 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
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.
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.
- Using Cloud External Key Manager (Cloud EKM) to manage keys is not supported in the preview launch stage of this feature.