Cloud KMS with Autokey

Cloud KMS Autokey simplifies creating and using customer-managed encryption keys (CMEKs) by automating provisioning and assignment. With Autokey, your key rings, keys, and service accounts don't need to be planned and provisioned before they're needed. Instead, Autokey generates your keys on demand as your resources are created, relying on delegated permissions instead of Cloud KMS administrators.

Using keys generated by Autokey can help you consistently align with industry standards and recommended practices for data security, including the HSM protection level, separation of duties, key rotation, location, and key specificity. Autokey creates keys that follow both general guidelines and guidelines specific to the resource type for Google Cloud services that integrate with Cloud KMS Autokey. After they are created, keys requested using Autokey function identically to other Cloud HSM keys with the same settings.

Autokey can also simplify usage of Terraform for key management, removing the need to run infrastructure-as-code with elevated key-creation privileges.

To use Autokey, you must have an organization resource that contains a folder resource. For more information about organization and folder resources, see Resource hierarchy.

Cloud KMS Autokey is available in all Google Cloud locations where Cloud HSM is available. For more information about Cloud KMS locations, see Cloud KMS locations. There is no additional cost to use Cloud KMS Autokey. Keys created using Autokey are priced the same as any other Cloud HSM keys. For more information about pricing, see Cloud Key Management Service pricing.

For more information about Autokey, see Autokey overview.

Choose between Autokey and other encryption options

Cloud KMS with Autokey is like an autopilot for customer-managed encryption keys: it does the work on your behalf, on demand. You don't need to plan keys ahead of time or create keys that might never be needed. Keys and key usage are consistent. You can define the folders where you want Autokey to be used and control who can use it. You retain full control of the keys created by Autokey. You can use manually-created Cloud KMS keys alongside keys created using Autokey. You can disable Autokey and continue to use the keys it created the same way you'd use any other Cloud KMS key.

Cloud KMS Autokey is a good choice if you want consistent key usage across projects, with a low operational overhead, and want to follow Google's recommendations for keys.

Feature or capability Google default encryption Cloud KMS Cloud KMS Autokey
Cryptographic isolation: keys are exclusive to one customer's account No Yes Yes
Customer owns and controls keys No Yes Yes
Developer triggers key provisioning and assignment Yes No Yes
Specificity: keys are automatically created at the recommended key granularity No No Yes
Lets you crypto-shred your data No Yes Yes
Automatically aligns with recommended key management practices No No Yes
Uses HSM-backed keys that are FIPS 140-2 Level 3 compliant No Optional Yes

If you need to use a protection level other than HSM or a custom rotation period, you can use CMEK without Autokey.

Compatible services

The following table lists services that are compatible with Cloud KMS Autokey:

Service Protected resources Key granularity
Cloud Storage

Objects within a storage bucket use the bucket default key. Autokey doesn't create keys for storage.object resources.

One key per bucket
Compute Engine

Snapshots use the key for the disk that you are creating a snapshot of. Autokey doesn't create keys for compute.snapshot resources.

One key per resource

Autokey creates default keys for datasets. Tables, models, queries, and temporary tables within a dataset use the dataset default key.

Autokey doesn't create keys for BigQuery resources other than datasets. To protect resources that are not part of a dataset, you must create your own default keys at the project or organization level.

One key per resource
Secret Manager

Secret Manager is only compatible with Cloud KMS Autokey when creating resources using Terraform or the REST API.

One key per location within a project

What's next