Customer-managed encryption keys (CMEK)

This document provides an overview of using Cloud Key Management Service (Cloud KMS) for customer-managed encryption keys (CMEK). Using Cloud KMS CMEK gives you ownership and control of the keys that protect your data at rest in Google Cloud.

Comparison of CMEK and Google-owned and Google-managed keys

The Cloud KMS keys that you create are customer-managed keys. Google services that use your keys are said to have a CMEK integration. You can manage these CMEKs directly, or through Cloud KMS Autokey (Preview). The following factors differentiate Google's default encryption at rest from customer-managed keys:

Type of key	Customer-managed with Autokey (Preview)	Customer-managed (manual)	Google-owned and Google-managed (Google default)
Can view key metadata	Yes	Yes	Yes
Ownership of keys^1	Customer	Customer	Google
Can manage and control^2 keys^3	Key creation and assignment is automated. Customer manual control is fully supported.	Customer, manual control only	Google
Supports regulatory requirements for customer-managed keys	Yes	Yes	No
Key sharing	Unique to a customer	Unique to a customer	Data from multiple customers typically use the same key encryption key (KEK).
Control of key rotation	Yes	Yes	No
CMEK organization policies	Yes	Yes	No
Pricing	Varies - for more information, see Pricing. No additional cost for Autokey (Preview)	Varies - for more information, see Pricing	Free

¹ In legal terms, the owner of the key indicates who holds the rights to the key. Keys that are owned by the customer have tightly restricted access or no access by Google.

²Control of keys means setting controls on the kind of keys and how the keys are used, detecting variance, and planning corrective action if needed. You may control your keys, but delegate management of the keys to a third party.

³Management of keys includes the following capabilities:

• Create keys.
• Choose the protection level of the keys.
• Assign authority for management of the keys.
• Control access to keys.
• Control usage of keys.
• Set and modify the rotation period of keys, or trigger a rotation of keys.
• Change key status.
• Destroy key versions.

Default encryption with Google-owned and Google-managed keys

All data stored within Google Cloud is encrypted at rest using the same hardened key management systems that Google uses for our own encrypted data. These key management systems provide strict key access controls and auditing, and encrypt user data at rest using the AES-256 encryption standard. Google owns and controls the keys used to encrypt your data. You can't view or manage these keys or review key usage logs. Data from multiple customers might use the same key encryption key (KEK). No setup, configuration, or management is required.

For more information about default encryption in Google Cloud, see Default encryption at rest.

Customer-managed encryption keys (CMEK)

Customer-managed encryption keys are encryption keys that you own. This capability lets you have greater control over the keys used to encrypt data at rest within supported Google Cloud services, and provides a cryptographic boundary around your data. You can manage CMEKs directly in Cloud KMS, or automate provisioning and assignment by using Cloud KMS Autokey (Preview).

Services that support CMEK have a CMEK integration. CMEK integration is a server-side encryption technology that you can use in place of Google's default encryption. After CMEK is set up, the operations to encrypt and decrypt resources are handled by the resource service agent. Because CMEK-integrated services handle access to the encrypted resource, encryption and decryption can take place transparently, without end-user effort. The experience of accessing resources is similar to using Google's default encryption. For more information about CMEK integration, see What a CMEK-integrated service provides.

You can use unlimited key versions for each key.

To learn whether a service supports CMEK keys, see the list of supported services.

Using Cloud KMS incurs costs related to the number of key versions and cryptographic operations with those key versions. For more information about pricing, see Cloud Key Management Service pricing. No minimum purchase or commitment is required.

Customer-managed encryption keys (CMEK) with Cloud KMS Autokey

Preview — Autokey

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Cloud KMS Autokey simplifies creating and managing CMEK keys by automating provisioning and assignment. With Autokey, keyrings and keys are generated on demand as part of resource creation, and service agents that use the keys for encrypt and decrypt operations are automatically granted the necessary Identity and Access Management (IAM) roles.

Using keys generated by Autokey can help you consistently align with industry standards and recommended practices for data security, including key-data location alignment, key specificity, hardware security module (HSM) protection level, key rotation schedule, and separation of duties. Autokey creates keys that follow both general guidelines and guidelines specific to the resource type for Google Cloud services that integrate with Autokey. Keys created using Autokey function identically to other Cloud HSM (Cloud HSM) keys with the same settings, including support for regulatory requirements for customer-managed keys. For more information about Autokey, see Autokey overview.

When to use customer-managed keys

You can use manually-created CMEK keys or keys created by Autokey in compatible services to help you meet the following goals:

• Own your encryption keys.

• Control and manage your encryption keys, including choice of location, protection level, creation, access control, rotation, use, and destruction.

• Generate or maintain your key material outside of Google Cloud.

• Set policy regarding where your keys must be used.

• Selectively delete data protected by your keys in the case of off-boarding or to remediate security events (crypto-shredding).

• Use keys that are unique to a customer, establishing a cryptographic boundary around your data.

• Create keys that are unique to a customer to establish a cryptographic boundary around your data.

• Log administrative and data access to encryption keys.

• Meet current or future regulation that requires any of these goals.

What a CMEK-integrated service provides

Like Google's default encryption, CMEK is server-side, symmetric, envelope encryption of customer data. The difference from Google's default encryption is that CMEK protection uses a key that a customer controls. CMEK keys created manually or automatically using Autokey operate the same way during service integration.

• Cloud services that have a CMEK integration use keys you create in Cloud KMS to protect your resources.

• Services that are integrated with Cloud KMS use symmetric encryption.

• The protection level of the key is within your control.

• All keys are 256-bit AES-GCM.

• Key material never leaves the Cloud KMS system boundary.

• Your symmetric keys are used to encrypt and decrypt in the envelope encryption model.

CMEK-integrated services track keys and resources

• CMEK-protected resources have a metadata field that holds the name of the key that encrypts it. Generally, this will be customer-visible in the resource metadata.

• Key tracking tells you what resources a key protects.

• Keys can be listed by project.

CMEK-integrated services handle resource access

The principal that creates or views resources in the CMEK-integrated service does not require the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) for the CMEK used to protect the resource.

Each project resource has a special service account called a service agent that performs encryption and decryption with customer-managed keys. Once you give the service agent access to a CMEK, that service agent will use that key to protect the resources of your choice.

When a requester wants to access a resource encrypted with a customer-managed key, the service agent automatically attempts to decrypt the requested resource. If the service agent has permission to decrypt using the key, and you have not disabled or destroyed the key, the service agent provides encrypt and decrypt use of the key. Otherwise, the request fails.

No additional requester access is required, and since the service agent handles the encryption and decryption in the background, the user experience for accessing resources is similar to using Google's default encryption.

Using Autokey for CMEK

For each folder where you want to use Autokey, there is a one-time setup process. You can expect to choose a folder to work in with Autokey support, and an associated key project where Autokey stores the keys for that folder. For more information about enabling Autokey, see Enable Cloud KMS Autokey.

Compared to manually creating CMEK keys, Autokey does not require the following setup steps:

• Key administrators don't need manually create key rings or keys, or assign privileges to the service agents that encrypt and decrypt data. The Cloud KMS service agent does these actions on their behalf.

• Developers don't need to plan ahead to request keys prior to resource creation. They can request keys themselves from Autokey as needed, while still preserving separation of duties.

When using Autokey, there is only one step: the developer requests the keys as part of resource creation. Keys returned are consistent for the intended resource type.

Your CMEK keys created with Autokey behave in the same way as manually-created keys for the following features:

• CMEK-integrated services behave the same way.

• The key administrator can continue to monitor all keys created and used through the Cloud KMS dashboard and key usage tracking.

• Organization policies work in the same way with Autokey as they do with manually created CMEK keys.

For an overview of Autokey, see Autokey overview. For more information about creating CMEK-protected resources with Autokey, see Create protected resources using Cloud KMS Autokey.

Manually creating CMEK keys

When you manually create your CMEK keys, key rings, keys, and resource locations must be planned and created in advance of resource creation. You can then use your keys to protect the resources.

For the exact steps to enable CMEK, see the documentation for the relevant Google Cloud service. Some services, such as GKE, have multiple CMEK integrations for protecting different types of data related to the service. You can expect to follow steps similar to the following:

1. Create a Cloud KMS key ring or choose an existing key ring. When creating your key ring, choose a location that is geographically near to the resources you're protecting. The key ring can be in the same project as the resources you're protecting or in different projects. Using different projects gives you greater control over IAM roles and helps support separation of duties.

2. You create or import a Cloud KMS key in the chosen key ring. This key is the CMEK key.

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

4. When creating a resource, configure the resource to use the CMEK key. For example, you can configure a GKE cluster to use CMEK to protect data at rest on the boot disks of the nodes.

For a requester to gain access to the data, they don't need direct access to the CMEK key.

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

Caution: Some services can experience permanent data loss when the CMEK key remains disabled or inaccessible for too long.

CMEK compliance

Some services have CMEK integrations, and allow you to manage keys yourself. Some services instead offer CMEK compliance, meaning the temporary data and ephemeral key are never written to disk. For a complete list of integrated and compliant services, see CMEK compatible services.

Key usage tracking

Key usage tracking shows you the Google Cloud resources within your organization that are protected by your CMEK keys. Using key usage tracking, you can view the protected resources, projects, and unique Google Cloud products that use a specific key, and whether keys are in use. For more information about key usage tracking, see View key usage

CMEK organization policies

Google Cloud offers organization policy constraints to help ensure consistent CMEK usage across an organization resource. These constraints provide controls to Organization Administrators to require CMEK usage and to specify limitations and controls on the Cloud KMS keys used for CMEK protection, including:

• Limits on which Cloud KMS keys are used for CMEK protection

• Limits on the allowed protection levels of keys

• Limits on the location of CMEK keys

• Controls for key version destruction

For more information about organization policies for CMEK, see CMEK organization policies.

What's next

• See the list of services with CMEK integrations.
• See the list of CMEK-compliant services.
• See the list of resource types that can have key usage tracking.
• See the list of services supported by Autokey.