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 encryption keys

The Cloud KMS keys that you create are customer-managed keys.Google Cloud services that use your keys are said to have aCMEK integration.You can manage these CMEKs directly, or throughCloud KMS Autokey. The followingfactors differentiate Google Cloud's default encryption at rest fromcustomer-managed keys:

Type of key	Cloud KMS Autokey	Cloud KMS customer-managed (manual)	Google-owned and Google-managed encryption key (Google default encryption)
Can view key metadata	Yes	Yes	No
Ownership of keys1	Customer	Customer	Google
Can manage2 and control3 keys	Key creation and assignment is automated. Customer manual control isfully 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 is typically protected by shared key encryptionkeys (KEKs).
Control of key rotation	Yes	Yes	No
CMEKorganization policies	Yes	Yes	No
Logadministrative and data access to encryption keys	Yes	Yes	No
Logical data separation through encryption	Yes	Yes	No
Pricing	Varies	Varies	Free

¹ The owner of the key indicates who holds therights to the key. Keys that you own have tightly restricted access or no accessby Google.

² Management of keys includes the followingtasks:

• 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.

³ Control of keys means setting controls on thekind of keys and how the keys are used, detecting variance, and planningcorrective action if needed. You can control your keys, but delegate managementof the keys to a third party.

Default encryption with Google-owned and Google-managed encryption keys

All data stored within Google Cloud is encrypted at rest using the samehardened key management systems that Google Cloud uses for our ownencrypted data. These key management systems provide strict key access controlsand auditing, and encrypt user data at rest using the AES-256 encryptionstandard. Google Cloud owns and controls the keys used to encrypt yourdata. You can't view or manage these keys or review key usage logs. Data frommultiple 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, seeDefault encryption at rest.

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 in Cloud KMS, or automate provisioningand assignment by usingCloud KMS Autokey.

Services that support CMEK have aCMEK integration. CMEK integration is aserver-side encryption technology that you can use in place ofGoogle Cloud's default encryption. After CMEK is set up, the operations toencrypt and decrypt resources are handled by the resource service agent. BecauseCMEK-integrated services handle access to the encrypted resource, encryption anddecryption can take place transparently, without end-user effort. The experienceof accessing resources is similar to using Google Cloud's defaultencryption. 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 CMEKs, 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 about pricing, seeCloud Key Management Service pricing. Nominimum purchase or commitment is required.

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

Cloud KMS Autokey simplifies creating and managing CMEKs 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, multi-tenant hardware (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 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 encryption keys

You can use manually-created CMEKs 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 key material in Cloud KMS or import key material that ismaintained 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-boardingor to remediate security events (crypto-shredding).

• Create and use keys that are unique to a customer, establishing acryptographic boundary 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 Cloud's default encryption, CMEK is server-side, symmetric,envelope encryption of customer data. The difference from Google Cloud'sdefault encryption is that CMEK protection uses a key that a customer controls.CMEKs created manually or automatically using Autokey operate the sameway during service integration.

• Cloud services that have aCMEK integrationuse keys you create in Cloud KMS to protect your resources.

• Services that are integrated with Cloud KMS use symmetricencryption.

• You choose theprotection level of the key.

• 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 key protects, forservices that support key tracking.

• Keys can belisted 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 agent that performs encryption and decryption withcustomer-managed keys. After you give the service agent access to a CMEK, thatservice agent will use that key to protect the resources of your choice.

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 Cloud'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, seeEnable Cloud KMS Autokey.

Compared to manually creating CMEKs, Autokey does not require thefollowing setup steps:

• Key administrators don't need to manually create key rings or keys orassign privileges 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 you use Autokey, there is only one step: the developer requeststhe keys as part of resource creation. Keys returned are consistent for theintended resource type.

Your CMEKs 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 CMEKs.

For an overview of Autokey, seeAutokey overview. For more information aboutcreating CMEK-protected resources with Autokey, seeCreate protectedresources using Cloud KMS Autokey.

Manually creating CMEKs

When you manually create your CMEKs, you must plan and create key rings, keys,and resource locations before you can create protected resources.You can then use your 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:

1. 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 helpssupportseparation of duties.

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

3. You grant theCryptoKey Encrypter/Decrypter IAMrole(roles/cloudkms.cryptoKeyEncrypterDecrypter) on the CMEK to the serviceaccount for the service.

4. When creating a resource, configure the resource to use the CMEK. Forexample, you can configure a BigQuery table toprotect data atrest in the table.

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

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

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

CMEK compliance

Some services have CMEK integrations, and allow you to manage keys yourself.Some services instead offerCMEK 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 CMEKs. 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, seeView 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 specify limitations and controlson the Cloud KMS keys used for CMEK protection, including thefollowing:

• Limits onwhich Cloud KMS keys are used for CMEKprotection

• Limits on the allowedprotection levels of keys

• Limits on thelocation of CMEKs

• Controls forkey version destruction

What's next

• See the list ofservices with CMEKintegrations.
• See the list ofCMEK-compliantservices.
• See the list ofresource types that canhave key usage tracking.
• See thelist of services supported byAutokey.