Customer-managed encryption keys (CMEK)

This topic provides an overview of Customer-managed encryption keys (CMEK) and the ways you can control the keys that protect your data at rest in Google Cloud.

Default encryption

All data stored within Google Cloud is encrypted at rest using the same hardened key management systems that we use for our own encrypted data. These key-management systems provide strict key access controls and auditing, and encrypt user data at rest using AES-256 encryption standards. No setup, configuration, or management is required. Google Cloud's default encryption at rest is the best choice for users who don't have specific requirements related to compliance or locality of cryptographic material.

Customer-managed encryption keys (CMEK)

If you need more control over the keys used to encrypt data at rest within a Google Cloud project, several Google Cloud services offer the ability to protect data related to those services using encryption keys managed by the customer within Cloud KMS. These encryption keys are called customer-managed encryption keys (CMEK). When you protect data in Google Cloud services with CMEK, the CMEK key is within your control.

Using CMEK doesn't necessarily provide more security than Google's default encryption mechanisms. In addition, using CMEK incurs additional costs related to Cloud KMS. Using CMEK gives you control over more aspects of the lifecycle and management of your keys, such as (but not limited to) the following abilities:

  • You can control Google's ability to decrypt data at rest by disabling the keys used to protect that data.
  • You can protect your data using a key that meets specific locality or residency requirements.
  • You can automatically or manually rotate the keys used to protect your data.
  • You can protect your data using a Cloud HSM key or a Cloud External Key Manager key, or an existing key that you import into Cloud KMS.
  • You can protect your data using a more strict encryption standard than AES-256.

CMEK integrations

When a service supports CMEK, it is said to have a CMEK integration. Some services, such as GKE, have multiple CMEK integrations for protecting different types of data related to the service.

For the exact steps to enable CMEK, see the documentation for the relevant Google Cloud service. You can expect to follow steps similar to these:

  1. You create or import a Cloud KMS key, selecting a location as geographically near as possible to the location of the service's resources. The service and the key can be in the same project or different projects. This is the CMEK key.

  2. You grant the CryptoKey Encrypter/Decrypter IAM role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the CMEK key to the service account for the service.

  3. You configure the service to use the CMEK key to protect its data. For example, you can configure a GKE cluster to use CMEK to protect data at rest on the boot disks of the nodes.

As long as the service account has this role, the service can encrypt and decrypt its data. If you revoke the role, or if you disable or destroy the CMEK key, that data can't be accessed.

CMEK compliance

Some services do not directly store data, or store data for only a short period of time, as an intermediate step in a long-running operation. For this type of workload, it's not practical to encrypt each write separately. These services don't offer CMEK integrations, but can offer CMEK compliance, often with no configuration on your part.

A CMEK-compliant service encrypts temporary data by using an ephemeral key that only exists in memory and is never written to disk. When the temporary data is no longer needed, the ephemeral key is flushed from memory, and the encrypted data can't be accessed, even if the storage resource still exists.

A CMEK-compliant service might offer the ability to send its output to a service with a CMEK integration, such as Cloud Storage.

What's next