This document provides an overview of using Cloud Key Management Service (Cloud KMS) forcustomer-managed encryption keys (CMEK). Using Cloud KMS CMEK gives youownership and control of the keys that protect your data at rest inGoogle Cloud.
Comparison of CMEK and Google-owned and Google-managed keys
The Cloud KMS keys that you create are customer-managed keys. Googleservices that use your keys are said to have a CMEK integration. You canmanage these CMEKs directly, or throughCloud KMS Autokey(Preview).The following factors differentiate Google's default encryption at rest fromcustomer-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 keys1 | Customer | Customer | |
| Can manage and control2 keys3 | Key creation and assignment is automated. Customer manual control is fully supported. | Customer, manual control only | |
| 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 |
1 In legal terms, the owner of the key indicates who holds the rightsto the key. Keys that are owned by the customer have tightly restricted accessor no access by Google.
2Control of keys means setting controls on the kind of keys and howthe 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.
3Management 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 samehardened 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 ownsand controls the keys used to encrypt your data. You can't view or manage thesekeys or review key usage logs. Data from multiple customers might use the samekey encryption key (KEK). No setup, configuration, or management is required.
For more information about default encryption in Google Cloud, seeDefault encryption atrest.
Customer-managed encryption keys (CMEK)
Customer-managed encryption keys are encryption keys that you own. Thiscapability lets you have greater control over the keys used to encrypt dataat rest within supported Google Cloud services, and provides acryptographic boundary around your data. You can manage CMEKs directly inCloud KMS, or automate provisioning and assignment by usingCloud KMS Autokey(Preview).
Services that support CMEK have a CMEK integration. CMEK integration is aserver-side encryption technology that you can use in place of Google's defaultencryption. After CMEK is set up, the operations to encrypt and decryptresources are handled by the resource service agent. Because CMEK-integratedservices handle access to the encrypted resource, encryption and decryptioncan take place transparently, without end-user effort. The experience ofaccessing resources is similar to using Google's default encryption.For more information about CMEK integration, seeWhat a CMEK-integrated service provides.
You can use unlimited key versions for each key.
To learn whether a service supports CMEK keys, see thelist of supported services.
Using Cloud KMS incurs costs related to the number of key versions andcryptographic operations with those key versions. For more information aboutpricing, see Cloud Key Management Service pricing. No minimum purchase orcommitment is required.
Customer-managed encryption keys (CMEK) with Cloud KMS Autokey
Cloud KMS Autokey simplifies creating and managing CMEK keys by automatingprovisioning and assignment. With Autokey, keyrings and keys aregenerated on demand as part of resource creation, and service agents that usethe keys for encrypt and decrypt operations are automatically granted thenecessary Identity and Access Management (IAM) roles.
Using keys generated by Autokey can help you consistently align withindustry standards and recommended practices for data security, includingkey-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 andguidelines specific to the resource type for Google Cloud services thatintegrate with Autokey. Keys created using Autokey functionidentically to other Cloud HSM (Cloud HSM) keys with the same settings,including support for regulatory requirements for customer-managed keys. Formore information about Autokey, seeAutokey overview.
When to use customer-managed keys
You can use manually-created CMEK keys or keys created by Autokey incompatible 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 orto 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 cryptographicboundary around your data.
Log administrative and data access to encryptionkeys.
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, envelopeencryption of customer data. The difference from Google's default encryption isthat CMEK protection uses a key that a customer controls. CMEK keys createdmanually or automatically using Autokey operate the same way duringservice integration.
Cloud services that have a CMEK integrationuse keys you create in Cloud KMS to protect your resources.
Services that are integrated with Cloud KMS use symmetricencryption.
The protection level of the key is withinyour 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 envelopeencryption model.
CMEK-integrated services track keys and resources
CMEK-protected resources have a metadata field that holds the name of thekey that encrypts it. Generally, this will be customer-visible in theresource metadata.
Key tracking tells you what resources a keyprotects, for services that support key tracking.
Keys can be listed by project.
CMEK-integrated services handle resource access
The principal that creates or views resources in the CMEK-integrated servicedoes not require theCloud KMS CryptoKey Encrypter/Decrypter(roles/cloudkms.cryptoKeyEncrypterDecrypter) for the CMEK used to protect theresource.
Each project resource has a special service account called aservice agentthat performs encryption and decryption with customer-managed keys. Once yougive the service agent accessto a CMEK, that service agent will use that key to protect the resources of yourchoice.
When a requester wants to access a resource encrypted with a customer-managedkey, the service agent automatically attempts to decrypt the requested resource.If the service agent has permission to decrypt using the key, and you have notdisabled or destroyed the key, the service agent provides encrypt and decryptuse of the key. Otherwise, the request fails.
No additional requester access is required, and since the service agent handlesthe encryption and decryption in the background, the user experience foraccessing 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-timesetup process. You can expect to choose a folder to work in withAutokey support, and an associated key project where Autokeystores the keys for that folder. For more information about enablingAutokey, see Enable Cloud KMS Autokey.
Compared to manually creating CMEK keys, Autokey does not require thefollowing setup steps:
Key administrators don't need manually create key rings or keys, or assignprivileges to the service agents that encrypt and decrypt data. TheCloud KMS service agent does these actions on their behalf.
Developers don't need to plan ahead to request keys prior to resourcecreation. They can request keys themselves from Autokey as needed,while still preservingseparation of duties.
When using Autokey, there is only one step: the developer requests thekeys as part of resource creation. Keys returned are consistent for theintended resource type.
Your CMEK keys created with Autokey behave in the same way asmanually-created keys for the following features:
CMEK-integrated services behave the same way.
The key administrator can continue to monitor all keys created and usedthrough the Cloud KMS dashboard andkey usage tracking.
Organization policies work in the same way with Autokey as they dowith manually created CMEK keys.
For an overview of Autokey, seeAutokey overview. For more informationabout creating CMEK-protected resources with Autokey, seeCreate protected resources using Cloud KMS Autokey.
Manually creating CMEK keys
When you manually create your CMEK keys, key rings, keys, and resource locationsmust be planned and created in advance of resource creation. You can then useyour keys to protect the resources.
For the exact steps to enable CMEK, see the documentation for the relevantGoogle Cloud service. Some services, such as GKE,have multiple CMEK integrations for protecting different types of data relatedto the service. You can expect to follow steps similar to the following:
Create a Cloud KMS key ring or choose an existing key ring. Whencreating your key ring, choose a location that is geographically near to theresources you're protecting. The key ring can be in the same project as theresources you're protecting or in different projects. Using differentprojects gives you greater control over IAM roles and helpssupport separation of duties.
You create or import a Cloud KMS key in the chosen key ring. Thiskey is the CMEK key.
You grant the CryptoKey Encrypter/Decrypter IAMrole(
roles/cloudkms.cryptoKeyEncrypterDecrypter) on the CMEK key to theservice account for the service.When creating a resource, configure the resource to use the CMEK key. Forexample, you can configure a GKE cluster to use CMEK toprotect data at rest on the boot disks of thenodes.
For a requester to gain access to the data, they don't need direct access to theCMEK key.
As long as the service agent has the CryptoKey Encrypter/Decrypterrole, the service can encrypt and decrypt its data. If you revoke this role, orif you disable or destroy the CMEK key, that data can't be accessed.
CMEK compliance
Some services have CMEK integrations, and allow you to manage keys yourself.Some services instead offer CMEK compliance, meaning the temporary data andephemeral key are never written to disk. For a complete list of integrated andcompliant services, seeCMEK compatible services.
Key usage tracking
Key usage tracking shows you the Google Cloud resources within yourorganization that are protected by your CMEK keys. Using key usage tracking, youcan view the protected resources, projects, and unique Google Cloud productsthat use a specific key, and whether keys are in use. For more information aboutkey usage tracking, see View key usage
CMEK organization policies
Google Cloud offers organization policy constraints to help ensureconsistent CMEK usage across an organization resource. These constraints providecontrols to Organization Administrators torequire CMEK usage and to specifylimitations and controls on the Cloud KMS keys used for CMEKprotection, 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, seeCMEK organization policies.
What's next
- See the list of services with CMEKintegrations.
- See the list of CMEK-compliantservices.
- See the list ofresource types that canhave key usage tracking.
- See the list of services supported byAutokey.
