This page describes how customer-managed encryption keys (CMEK) work with Memorystore for Redis Cluster. To use this feature right away, see Use customer-managed encryption keys (CMEK).
Who should use CMEK?
CMEK is 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 Cluster. For CMEK-enabled Memorystore for Redis Cluster instances, Google uses your keys to access all data at rest.
Memorystore uses Google-managed data encryption keys (DEK) and key encryption keys (KEK) to encrypt data in Memorystore for Redis Cluster. There are two levels of encryption:
- DEK encryption: Memorystore uses DEKs to encrypt data in Memorystore for Redis Cluster.
- KEK encryption: Memorystore uses KEKs to encrypt DEKs.
The Memorystore for Redis Cluster instance stores the encrypted DEK alongside the encrypted data on disk and Google manages the Google KEK. With CMEK, you create a key that wraps the Google KEK. CMEK lets you create, disable or destroy, rotate, and enable or restore the KEK.
The following diagrams show how data-at-rest encryption works inside a Memorystore for Redis Cluster instance when using default Google-managed encryption versus CMEK.
Without CMEK
With CMEK
When decrypting data wrapped with CMEK, Memorystore uses the KEK from Cloud Key Management Service to decrypt the DEK and the unencrypted DEK to decrypt data-at-rest.
Pricing
Memorystore for Redis Cluster bills for a CMEK-enabled cluster just like any other cluster; there are no additional costs. For more information, see Memorystore for Redis Cluster pricing.
You use the Cloud KMS API to manage CMEK. When you create a Memorystore for Redis Cluster instance with CMEK, Memorystore uses the key periodically to encrypt data to ensure that the permissions for the key are correct and that the key is enabled.
You're billed by Cloud KMS for the cost of the key and for encryption and decryption operations when Memorystore for Redis Cluster uses the key. For more information, see Cloud KMS pricing.
Which data is encrypted using CMEK?
CMEK encrypts the following types of customer data that are stored in persistent storage:
- Backups: Backups let you recover your data to a point in time, and export and analyze data. Backups are also useful for disaster recovery, data migration, data sharing, and compliance scenarios.
- Persistence: Memorystore for Redis Cluster supports two types of persistence:
- RDB persistence: The Redis database (RDB) feature protects your data by saving snapshots of your data on durable storage.
- AOF persistence: This feature prioritizes data durability. It stores data durably by recording every write command to a log file called the Append-Only File (AOF). If a system failure or restart occurs, then the server replays AOF file commands sequentially to restore your data.
About service accounts
When creating an instance with CMEK you must grant the cloudkms.cryptoKeyEncrypterDecrypter role to the Memorystore for Redis Cluster 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 Grant the Memorystore for Redis Cluster service account access to the key.
About keys
In Cloud KMS, you need to create a key ring with a cryptographic key that uses a symmetric encryption algorithm. When you create a new Memorystore for Redis Cluster instance, you select this key to encrypt the instance. You can create one project for both your keys and instances, or different projects for each of them.
CMEK is available in all Memorystore for Redis Cluster instance locations. You must set the key and key ring region to the same region as the instance. A multi-region or global region key doesn't work. If the regions don't match, then a request for creating an instance fails.
CMEK uses the following format:
projects/[CMEK_ENABLED_PROJECT]/locations/[REGION]/keyRings/[KEY_RING_NAME]/cryptoKeys/[KEY_NAME]
How do you make CMEK-encrypted data inaccessible permanently?
You might have situations where you want to destroy data encrypted with CMEK permanently. To do this, you destroy the key version. You can't destroy the key ring or key, but you can destroy the versions of the key.
Behavior of a CMEK key version
This section provides information about what happens when you disable, destroy, rotate, enable, and restore a key version.
Disable or destroy a CMEK key version
If you disable or destroy the primary key version of your CMEK, then the following conditions apply for backups and persistence.
Backups
- You can't create on-demand or automated backups. However, if you enable an older key version, then you can access any backups that you created using this key version.
- You can't update or re-enable automated backups until you enable or restore the primary key version.
Persistence
- If you enable persistence, then Memorystore for Redis Cluster performs an update that's similar to the one used in maintenance and disables the Persistence feature. You're no longer charged for this feature.
- Memorystore for Redis Cluster doesn't flush new data to persistent storage using the CMEK.
- Memorystore for Redis Cluster can't read existing data that's present in the persistent storage.
- You can't update or re-enable persistence until you enable or restore the primary key version.
If you enable the primary key version of your CMEK, but you disable or destroy an older key version, then the following conditions apply for backups and persistence:
- You can create backups. However, if a backup is encrypted with an older key version that's disabled or destroyed, then the backup remains inaccessible.
- If you enable persistence, then this feature remains enabled. If the older key version that's used in persistence is disabled or destroyed, then Memorystore for Redis Cluster performs an update that's similar to the one that's used in maintenance and re-encrypts the data with the primary key version.
Rotate the primary CMEK key version
If you rotate the primary key version of your CMEK and create a new primary key version, then the following conditions apply for backups and persistence:
- The latest primary key version of your CMEK encrypts new backups.
- For existing backups, no re-encryption is done.
- For persistence, the VMs don't take any action. The VMs continue to use the older key version until the next maintenance event.
Enable or restore the primary CMEK key version
If you enable or restore the primary key version of your CMEK, then the following conditions apply for backups and persistence:
- You can create on-demand and automated backups again.
- Memorystore for Redis Cluster performs an update that's similar to the one used in maintenance and re-enables persistence.
Limitations
The following limitations apply when using CMEK with Memorystore for Redis Cluster:
- You can't enable CMEK on an existing Memorystore for Redis Cluster deployment.
- The region for the key, key ring, and instance must all be the same.
- You must use the symmetric encryption algorithm for your key.
- Cloud KMS encryption and decryption rates are subject to a quota.