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 Valkey instances, instead of relying on Google's default encryption. 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 Memorystore for Valkey instances. To encrypt this data, Memorystore for Valkey 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 Valkey.
  • KEK encryption: KEKs encrypt DEKs.

Memorystore for Valkey 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.

Data is uploaded to Google's storage infrastructure and divided into chunks. Each chunk is encrypted with its own DEK. The DEKs are then encrypted using a KEK that's retrieved from Cloud KMS. The encrypted chunks and encrypted DEKs are distributed across the storage infrastructure.

The following diagram shows how Memorystore for Valkey decrypts data that's encrypted with CMEK. To access this encrypted data, Memorystore for Valkey 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.

Data chunk encrypted with DEK and stored with the encrypted DEK. A request to descrypt the DEK is sent to Cloud KMS, which stores the KEK. Cloud KMS returns the decrypted DEK.

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 Valkey supports two types of persistence:
    • RDB persistence: save snapshots of your data on durable storage.
    • AOF persistence: store 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.

CMEK components

The following sections describe the requirements and behaviors of the service accounts, cryptographic keys, key versions, and organization policies that make up your CMEK architecture.

Service accounts

To create a CMEK-enabled instance, you must grant the roles/cloudkms.cryptoKeyEncrypterDecrypter role to the Memorystore for Valkey service account that uses the following format:

service-PROJECT_NUMBER@gcp-sa-memorystore.iam.gserviceaccount.com

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

Keys

In Cloud KMS, you need to create a key ring, and then create a cryptographic key that uses a symmetric encryption algorithm. When you create a Memorystore for Valkey 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 Valkey instance locations. You must create the key ring and key in the same region where you want to create the instance. For a multi-region instance, you must set the key ring and key to the same location as the instance. 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

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

External keys

As part of your CMEK strategy, you can use external keys. To do this, use Cloud External Key Manager (Cloud EKM) to encrypt data within Google Cloud by using external keys that you manage.

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

Key versions

Cloud KMS stores the cryptographic key material that you use to encrypt and decrypt your data in a key version. A single key can contain multiple key versions. Whenever you rotate a key, you create a key version.

The following sections describe how your instances and their protected data behave during key lifecycle events, such as disabling, destroying, rotating, enabling, or restoring key versions. The sections also explain the impact of revoking access to or replacing a Cloud KMS key, and provide guidance on manually re-encrypting data.

Disabling or destroying a CMEK key version

You might have situations where you want to make data that's encrypted with CMEK permanently inaccessible, such as when you're remediating a data spill. To achieve this high-assurance data destruction (also known as crypto-shredding), you destroy the key version. For more information about destroying key versions, see Destroy and restore key versions.

If you disable or destroy the primary key version of your CMEK, then the following conditions apply for backups and persistence.

Backups

When you destroy the primary key version of your CMEK, the following restrictions apply to your instance's 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. For more information, see Enabling or restoring the primary CMEK key version.
Persistence

When you destroy the primary key version of your CMEK, the following restrictions apply to persistence for your instance:

  • If you configure your instance to use persistence, then Memorystore for Valkey deactivates persistence when the key version becomes unavailable. You're no longer charged for using persistence.
  • Memorystore for Valkey doesn't flush new data to persistent storage using the CMEK.
  • Memorystore for Valkey 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 it remains enabled. If the older key version that's used in persistence is disabled or destroyed, then Memorystore for Valkey performs an update that's similar to the one that's used in maintenance and re-encrypts the data with the primary key version.

Revoking access to a Cloud KMS key

If you revoke access to an active Cloud KMS key by either disabling the key or removing IAM permissions for the key, then Memorystore for Valkey prioritizes the availability of the primary cache. Regular, in-memory caching operations continue to serve traffic.

However, backups and persistence are deactivated. Memorystore for Valkey immediately stops writing new data to the disk and doesn't read data from the customer-encrypted disk into memory.

Rotating 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 nodes don't take any action. The nodes continue to use the older key version until the next maintenance event.

Re-encrypting CMEK-protected data manually

Memorystore for Valkey doesn't support on-demand re-encrypting of stored data. 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.

If you rotate a key and must force an instance to use the new key version, then the following conditions apply for backups and persistence:

Backups

You can't re-encrypt existing backups. If compliance requires that all data must be encrypted with the newest key, create a backup that uses this key, and then delete existing backups manually. You can also export this backup to a Cloud Storage bucket so that the Cloud Storage encryption key is used.

Persistence

To force the instance to use a new Cloud KMS key, you can run simulated maintenance on the instance. After you complete this operation, Memorystore for Valkey can write persistence data by using the updated primary key version.

Replacing a protected Cloud KMS key

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

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

  • Backups: all subsequent backups are encrypted by using the new key. Existing backups maintain their original keys.
  • Persistence: the next time the instance restarts or has a maintenance event, the new 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 stored data.

Enabling or restoring 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 Valkey performs an update that's similar to the one used in maintenance and re-enables persistence.

Organization policy constraints

Memorystore for Valkey 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 Valkey 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.

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

Pricing

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

You use the Cloud KMS API to manage CMEK. When you create a Memorystore for Valkey 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 Valkey uses the key. For more information, see Cloud KMS pricing.

Limitations

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

  • You can't enable CMEK on an existing Memorystore for Valkey 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