Autokey overview

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

How Autokey works

This section explains how Cloud KMS Autokey works. The following user roles participate in this process:

Security administrator: The security administrator is a user who is responsible for managing security at the folder or organization level.
Autokey developer: The Autokey developer is a user who is responsible for creating resources using Cloud KMS Autokey.
Cloud KMS administrator: The Cloud KMS administrator is a user who is responsible for managing Cloud KMS resources. This role has fewer responsibilities when using Autokey than when using manually-created keys.

The following service agents also participate in this process:

Cloud KMS service agent: The service agent for Cloud KMS in a given key project. Autokey depends on this service agent having elevated privileges to create Cloud KMS keys and key rings and to set IAM policy on the keys, granting encrypt and decrypt permissions for each resource service agent.
Resource service agent: The service agent for a given service in a given resource project. This service agent must have encrypt and decrypt permissions on any Cloud KMS key before it can use that key for CMEK protection on a resource. Autokey creates the resource service agent when needed grants it the necessary permissions to use the Cloud KMS key.

Security administrator enables Cloud KMS Autokey

Before you can use Autokey, the security administrator must complete the following one-time setup tasks:

Enable Cloud KMS Autokey on a resource folder and identify the Cloud KMS project that will contain Autokey resources for that folder.
Create the Cloud KMS service agent and then grant key creation and assignment privileges to the service agent.
Grant Autokey user roles to Autokey developer users.

With this configuration complete, Autokey developers can now trigger Cloud HSM key creation on-demand. To see full setup instructions for Cloud KMS Autokey, see Enable Cloud KMS Autokey.

Autokey developers use Cloud KMS Autokey

After Autokey is successfully set up, authorized Autokey developers can now create resources protected using keys created for them on demand. The details of the resource creation process depend on which resource you are creating, but the process follows this flow:

The Autokey developer begins to create a resource in a compatible Google Cloud service. During resource creation, the developer requests a new key from the Autokey service agent.
The Autokey service agent receives the developer's request and completes the following steps:
1. Create a key ring in the key project at the selected location, unless that key ring already exists.
2. Create a key in the key ring with the appropriate granularity for the resource type, unless such a key already exists.
3. Create the per-project, per-service service account, unless that service account already exists.
4. Grant the per-project, per-service service account encrypt and decrypt permissions on the key.
5. Provide the key details to the developer so they can finish creating the resource.
With key details successfully returned by the Autokey service agent, the developer can immediately finish creating the protected resource.

Cloud KMS Autokey creates keys that have the attributes described in the next section. This key creation flow preserves separation of duties. The Cloud KMS administrator continues to have full visibility and control over keys created by Autokey.

To start using Autokey after enabling it on a folder, see Create protected resources using Cloud KMS Autokey.

About keys created by Autokey

Keys created by Cloud KMS Autokey have the following attributes:

Protection level: HSM
Algorithm: AES-256 GCM
Rotation period: one year

Once a key is created by Autokey, a Cloud KMS administrator can edit the rotation period from the default.
Separation of duties:
- The service account for the service is automatically granted encrypt and decrypt permissions on the key.
- Cloud KMS administrator permissions apply as usual to keys created by Autokey. Cloud KMS administrators can view, update, enable or disable, and destroy keys created by Autokey. Cloud KMS administrators are not given encrypt and decrypt permissions.
- Autokey developers can only request key creation and assignment. They cannot view or manage keys.
Key specificity or granularity: Keys created by Autokey have a granularity that varies by resource type. For service-specific details about key granularity, see Compatible services on this page.
Location: Autokey creates keys in the same location as the resource to be protected.

If you need to create CMEK protected resources in locations where Cloud HSM is not available, you must create your CMEK manually.
Key version state: newly-created keys requested using Autokey are created as the primary key version in the enabled state.
Key ring naming: all keys created by Autokey are created in a key ring called autokey in the Autokey project in the selected location. Key rings in your Autokey project are created when an Autokey developer requests the first key in a given location.
Key naming: key created by Autokey follow this naming convention:
```
PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
```
Like all Cloud KMS keys, keys created by Autokey can't be exported.
Like all Cloud KMS keys used in CMEK integrated services that are compatible with key tracking, keys created by Autokey are tracked in the Cloud KMS dashboard.

Enforcing Autokey

If you want to enforce usage of Autokey within a folder, you can do so by combining IAM access controls with CMEK organization policies. This works by removing key creation permissions from principals other than the Autokey service agent, and then requiring that all resources are protected by CMEK using the Autokey key project. For detailed instructions for enforcing the use of Autokey, see Enforce Autokey usage.

Compatible services

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

Service	Protected resources	Key granularity
Cloud Storage	`storage.googleapis.com/Bucket` 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	`compute.googleapis.com/Disk` `compute.googleapis.com/Image` `compute.googleapis.com/Instance` `compute.googleapis.com/MachineImage` 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
BigQuery	`bigquery.googleapis.com/Dataset` 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	`secretmanager.googleapis.com/Secret` 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

Limitations

You can't clear an AutokeyConfig resource. You can disable Autokey on the folder by updating the AutokeyConfig to set enabled=false, but the configured key project remains in the AutokeyConfig. You can change the configured key project by updating the AutokeyConfig.
The gcloud CLI is not available for Autokey resources.
Key handles are not in Cloud Asset Inventory.

What's next

To get started with Cloud KMS Autokey, a security administrator must enable Cloud KMS Autokey.
To use Cloud KMS Autokey after it has been enabled, a developer can create CMEK-protected resources using Autokey.