About customer-managed encryption keys (CMEK)

This document describes how you can use customer-managed encryption keys (CMEK) in Cloud Key Management Service (Cloud KMS) for your Memorystore for Redis instances. The document also outlines which data is encrypted in persistent storage and how your instances behave during key lifecycle events.

CMEK lets you control the cryptographic keys that protect your stored data. By managing your own keys in Cloud KMS, you gain greater control over key access, rotation, and usage, which helps you meet strict compliance and regulatory requirements.

Implementing CMEK provides an additional layer of security and control over your persistent data, such as backups and persistence files. You can enable CMEK only on new instances. You can't apply CMEK to existing instances.

Who should use CMEK?

CMEK is intended for organizations that have sensitive or regulated data, and require control over their own encryption keys. For more information about whether to use CMEK to encrypt this data, see Decide whether to use CMEK.

Customer-managed encryption

CMEK lets you use your cryptographic keys to protect stored data in instances. To encrypt this data, Memorystore for Redis uses Google-managed data encryption keys (DEKs) and customer-managed key encryption keys (KEKs).

You can have the following levels of encryption:

• DEK encryption: DEKs encrypt data in Memorystore for Redis.
• KEK encryption: KEKs encrypt DEKs.

Memorystore for Redis uses KEKs to encrypt DEKs, and it uses DEKs to encrypt the stored data. If you use CMEK, then you can manage the KEKs that encrypt the DEKs in your instance.

The following diagram shows how an instance uses CMEK to encrypt data. Data that's uploaded to Google's storage infrastructure is chunked, and each chunk is encrypted with its own DEK. Cloud KMS provides the KEK to encrypt the DEKs, and Google's storage infrastructure distributes both the encrypted data chunks and the encrypted DEKs across the system.

The following diagram shows how Memorystore for Redis decrypts data that's encrypted with CMEK. To access this encrypted data, Memorystore for Redis sends a request to Cloud KMS, which manages the KEK, to decrypt the DEK. Cloud KMS then returns the decrypted DEK, which the instance uses to decrypt the stored data.

When does Memorystore interact with CMEK?

Operation	Description
Instance creation	When you create an instance, you configure it to use CMEK.
Instance update	During updates to a CMEK-enabled instance, Memorystore for Redis checks the CMEK.

Which 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 for Redis service account that has the following format:

  [e-mail]
  

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 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 Memorystore for Redis 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 instance locations. You must create the key ring and key in the same region where you want to create the instance. A key for a multi-region or global region doesn't work. If the regions or locations don't match, then a request for creating the instance fails.

For the resource ID of the key, CMEK uses the following format:

projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME

Note: For more information about finding the resource IDs of existing keys, see Getting a Cloud KMS resource ID.

If Memorystore for Redis can't access any key version being used (for example, you disable all key versions), then Memorystore for Redis shuts down the instance. In the Google Cloud console, a suspended instance shows a red exclamation mark tooltip on the Instances page. If you hover over the tooltip, then a No state status appears. After the key becomes accessible, Memorystore for Redis resumes the instance automatically.

Warning: Avoid disabling or destroying any version of the key that Memorystore for Redis uses to encrypt the instance. Disabling or destroying any key version can suspend the instance.

External keys

You can use Cloud External Key Manager (Cloud EKM) to encrypt data within Google Cloud using external keys that you manage.

When you use a Cloud EKM key, Google has no control over the availability of your externally managed key. If the key isn't available when you create your instance, then the instance isn't created.

For more considerations when using external keys, see Cloud External Key Manager.

How do you make CMEK-encrypted data inaccessible permanently?

Warning: You have control over keys and data access. After you destroy a key version that's associated with a Memorystore for Redis instance, Google can't get the data back. However, if you re-enable the instance, you can restore data by importing a backup.

You might have situations where you want to make data that's encrypted with CMEK inaccessible permanently. To do this, you destroy the key version. For more information about destroying versions of the key, see Destroy and restore key versions.

How do you import or export data for a CMEK-enabled instance?

If you want your data to remain encrypted with a CMEK when you export data, then you must set a CMEK on the Cloud Storage bucket before you export data to it.

If your data is stored on a CMEK-enabled instance, then there are no special requirements or restrictions for importing data into a new instance.

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 want to ensure no data access to your instance, then disable your primary key version. This shuts down your instance. Also, if any CMEK that's in use is disabled or destroyed, then Memorystore for Redis shuts down the instance. This includes any older key version that the instance uses.

To see if Memorystore for Redis suspends your instance, use one of the following interfaces:

• Google Cloud console: in the Instances page, a red exclamation mark tooltip appears next to your instance. If you hover over the tooltip, then a No state status appears.
• gcloud CLI: use the gcloud redis instances describe command. Verify that you don't see state: READY, state: REPAIRING, or any other state in the instance metadata.

Re-encrypt CMEK-protected data manually

Memorystore for Redis doesn't support on-demand rewrapping of existing data at rest. You can't trigger a process manually to use a new key version to re-encrypt existing backups or active persistence files. However, you can use the new key version to encrypt newly written data.

Replace a protected KMS key

If you replace a protected KMS key with either a different KMS key or a new primary key version, then Memorystore for Redis applies this change only to future operations.

Replacing a protected KMS key impacts your resources in the following ways:

• Backups: Memorystore for Redis exports backups to Cloud Storage buckets. The Cloud Storage encryption key controls the key that's used to encrypt the data.
• Persistence: the next time the instance restarts or has a maintenance event, the new KMS key is used.
• Primary cache: replacing this key has no impact. CMEK doesn't encrypt in-memory data because this data isn't considered as data at rest.

Important: If you revoke access to an active KMS key by either disabling the key or removing IAM permissions for the key, then Memorystore for Redis deactivates the instance.

Enable or restore the primary CMEK key version

If you enable or restore your primary key version, then Memorystore for Redis no longer hides your instance.

Organization policy constraints

Memorystore for Redis supports organization policy constraints for CMEK. By using these constraints, you can enforce CMEK protection for your instances and limit which Cloud KMS keys you can use for this protection.

You can configure the following organization policy constraints:

• constraints/gcp.restrictNonCmekServices: use this constraint to enforce CMEK protection for your instances. If the Memorystore for Redis API is in the Deny policy list of services for this constraint, then you can't create non-CMEK-protected instances.
• constraints/gcp.restrictCmekCryptoKeyProjects: use this constraint to limit which Cloud KMS keys you can use for CMEK protection. If you configure this constraint, then the instances that use CMEK encryption must use a key from an allowed project, folder, or organization.

Because both Memorystore for Redis and Memorystore for Redis Cluster share the same endpoint (redis.googleapis.com), you can't enforce CMEK for instances independently from clusters in Memorystore for Redis Cluster.

For more information about the CMEK-related organization policy constraints that Google manages for Memorystore for Redis, see Organization policy constraints.

Pricing

Memorystore for Redis bills for a CMEK-enabled instance just like any other instance; there are no additional costs. For more information, see Memorystore for Redis pricing.

You use the Cloud KMS API to manage CMEK. When you create an instance with CMEK, Memorystore uses the key periodically to encrypt data.

You're billed by Cloud KMS for the cost of the key and for encryption and decryption operations when Memorystore for Redis uses the key. For more information, see Cloud KMS pricing.

Limitations

The following limitations apply when using CMEK with Memorystore for Redis:

• You can't enable CMEK on an existing instance.
• The key, key ring, and instance must be located in the same region.
• You must use the symmetric encryption algorithm for your key.
• Cloud KMS encryption and decryption rates are subject to a quota.

What's next

• Learn more about CMEK.
• Learn how to enhance data security by using CMEK.
• Learn more about backups.
• Learn more about persistence.