Autokey overview

Cloud KMS Autokey simplifies creating and using customer-managed encryption keys (CMEKs) by automating provisioning and assignment. With Autokey, key rings and keys are generated on-demand. Service accounts that use the keys to encrypt and decrypt resources are created and granted Identity and Access Management (IAM) roles when needed. Cloud KMS administrators retain full control and visibility of keys created by Autokey, without needing to pre-plan and create each resource.

Using keys generated by Autokey can help you consistently align with industry standards and recommended practices for data security, including the Multi-tenant Cloud 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.

You can use Autokey with a centralized key management model (Generally Available) or a delegated key management model (Preview). To use the centralized key management model, you must have an organization resource that contains a folder resource. In the centralized model, Autokey is enabled for projects within a folder, and keys created by Autokey are created in a dedicated key project for that folder. With the delegated key management model, key management is delegated to project administrators, who can enable Autokey on a folder or project to let Autokey create keys in the same project as the resources they protect.

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:

Administrator

The administrator is a user who's 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 and grants it the necessary permissions to use the Cloud KMS key.

Administrator enables Cloud KMS Autokey

Enabling Autokey follows one of the following paths based on your chosen key management model:

1. Centralized key management model: Enable Autokey on a folder. A centralized key project is created to hold the keys that protect resources created in other projects within the folder.
2. Delegated key management model (Preview): You can enable Autokey on individual projects or for all projects within a folder to use same-project Autokey.

Enable centralized key management

Before you can use Autokey for centralized key management in a folder, an administrator must complete the following one-time setup tasks:

1. Enable Cloud KMS Autokey on a folder and identify the Cloud KMS project that will contain Autokey resources for that folder.

2. Create the Cloud KMS service agent and then grant key creation and assignment privileges to the service agent.

With this configuration complete, developers who can create Autokey compatible resources in any project in that folder can now trigger Multi-tenant Cloud HSM key creation on-demand. To see full setup instructions for Cloud KMS Autokey, see Enable Cloud KMS Autokey.

Enable delegated key management

Preview

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.

Before you can use Autokey for delegated key management, an administrator must complete the following one-time setup tasks:

1. Enable Cloud KMS Autokey on a project or folder.
2. Enable the Cloud KMS API on that project or projects in the folder.

When Cloud KMS Autokey is enabled on a project for delegated key management, the Cloud KMS service agent is created for you when needed. You don't have to manually create the service agent. Any user with permissions to create an Autokey compatible resource can request a new key 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 enabled for a project, Autokey developers can create resources protected using keys created for them on demand. This applies to projects in a folder where Autokey is enabled for centralized key management and projects where Autokey is enabled for delegated, same-project key management. The details of the resource creation process depend on which resource you are creating, but the process follows this flow:

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

2. The Autokey service agent receives the developer's request and completes the following steps:

   1. Create a key ring in the 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.

3. 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, 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.

  After 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: Keys created by Autokey follow this naming convention: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
• Key export: Like all Cloud KMS keys, keys created by Autokey can't be exported.
• Key tracking: 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 or project, 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
Artifact Registry	artifactregistry.googleapis.com/Repository Autokey creates keys during Repository creation, used for all stored artifacts.	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
Bigtable	bigtableadmin.googleapis.com/Cluster Autokey creates keys for clusters. Autokey doesn't create keys for Bigtable resources other than clusters. Bigtable is only compatible with Cloud KMS Autokey when creating resources using Terraform or the Google Cloud SDK.	One key per cluster
AlloyDB for PostgreSQL	alloydb.googleapis.com/Cluster alloydb.googleapis.com/Backup AlloyDB for PostgreSQL is only compatible with Cloud KMS Autokey when creating resources using Terraform or the REST API.	One key per resource
Cloud Run	run.googleapis.com/Service run.googleapis.com/Job	One key per location within a project
Cloud SQL	sqladmin.googleapis.com/Instance Autokey doesn't create keys for Cloud SQL BackupRun resources. When you create a backup of a Cloud SQL instance, the backup is encrypted with the primary instance's customer-managed key. Cloud SQL is only compatible with Cloud KMS Autokey when creating resources using Terraform or the REST API.	One key per resource
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
Pub/Sub	pubsub.googleapis.com/Topic	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
Secure Source Manager	securesourcemanager.googleapis.com/Instance	One key per resource
Spanner	spanner.googleapis.com/Database Spanner is only compatible with Cloud KMS Autokey when creating resources using Terraform or the REST API.	One key per resource
Dataflow	dataflow.googleapis.com/Job	One key per resource
Dataproc	dataproc.googleapis.com/Cluster dataproc.googleapis.com/SessionTemplate dataproc.googleapis.com/WorkflowTemplate dataproc.googleapis.com/Batch dataproc.googleapis.com/Session	For Cluster, SessionTemplate, and WorkflowTemplate resources: One key per resource For Batch and Session resources: One key per location within a project

Limitations

• 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, an 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.
• Learn about CMEK best practices.