Cloud KMS Autokey simplifies creating and usingcustomer-managed encryptionkeys (CMEKs) by automating provisioning and assignment. WithAutokey, key rings and keys are generated on-demand. Service accountsthat use the keys to encrypt and decrypt resources are created and grantedIdentity and Access Management (IAM) roles when needed. Cloud KMS administratorsretain full control and visibility of keys created by Autokey, withoutneeding to pre-plan and create each resource.

Using keys generated by Autokey can help you consistently align withindustry standards and recommended practices for data security, including theMulti-tenant Cloud HSM protection level, separation of duties, key rotation,location, and key specificity. Autokey creates keys that follow bothgeneral guidelines and guidelines specific to the resource type forGoogle Cloud services that integrate with Cloud KMS Autokey. Afterthey are created, keys requested using Autokey function identically toother 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-creationprivileges.

You can use Autokey with a centralized key management model (GenerallyAvailable) or a delegated key management model (Preview). To usethe centralized key management model, you must have an organization resourcethat contains a folder resource. In the centralized model, Autokey isenabled for projects within a folder, and keys created by Autokey arecreated in a dedicated key project for that folder. With the delegated keymanagement model, key management is delegated to project administrators, who canenable Autokey on a folder or project to let Autokey createkeys in the same project as the resources they protect.

For more information about organization and folder resources,seeResource hierarchy.

Cloud KMS Autokey is available in all Google Cloud locations whereCloud HSM is available. For more information about Cloud KMSlocations, seeCloud KMS locations. There is noadditional cost to use Cloud KMS Autokey. Keys created usingAutokey are priced the same as any other Cloud HSM keys. Formore information about pricing, seeCloud Key Management Service pricing.

How Autokey works

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

Administrator

The administrator is a user who's responsiblefor managing security at the folder or organization level.

Autokey developer

The Autokey developer is a user who isresponsible for creating resources using Cloud KMS Autokey.

Cloud KMS administrator

The Cloud KMS administrator is auser who is responsible for managing Cloud KMS resources. This rolehas fewer responsibilities when using Autokey than when usingmanually-created keys.

The following service agents also participate in this process:

Cloud KMS service agent

The service agent for Cloud KMS in agiven key project. Autokey depends on this service agent havingelevated privileges to create Cloud KMS keys and key rings and toset IAM policy on the keys, granting encrypt and decryptpermissions for each resource service agent.

Resource service agent

The service agent for a given service in a givenresource project. This service agent must have encrypt and decryptpermissions on any Cloud KMS key before it can use that key forCMEK protection on a resource. Autokey creates the resource serviceagent when needed and grants it the necessary permissions to use theCloud KMS key.

Administrator enables Cloud KMS Autokey

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

1. Centralized key management model: Enable Autokey on a folder. Acentralized key project is created to hold the keys thatprotect resources created in other projects within the folder.
2. Delegated key management model (Preview): You can enableAutokey on individual projects or for all projects within a folderto 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 theCloud KMS project that will contain Autokey resources forthat folder.

2. Create the Cloud KMSservice agent and then grantkey creation and assignment privileges to the service agent.

With this configuration complete, developers who can create Autokeycompatible resources in any project in that folder can now triggerMulti-tenant Cloud HSM key creation on-demand. To see full setup instructionsfor Cloud KMS Autokey, seeEnable Cloud KMS Autokey.

Enable delegated key management

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

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

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 KMSservice agent is created for you whenneeded. You don't have to manually create the service agent. Any user withpermissions to create an Autokey compatible resource can request anew key on demand. To see full setup instructions for Cloud KMS Autokey,seeEnable Cloud KMS Autokey.

Autokey developers use Cloud KMS Autokey

After Autokey is successfully enabled for a project, Autokeydevelopers can create resources protected using keys created for them ondemand. This applies to projects in a folder where Autokey is enabledfor centralized key management and projects where Autokey is enabledfor delegated, same-project key management. The details of the resource creationprocess depend on which resource you are creating, but the process follows thisflow:

1. The Autokey developer begins to create a resource in a compatibleGoogle Cloud service. During resource creation, the developer requestsa new key from the Autokey service agent.

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

   1. Create a key ring in the project at the selected location, unlessthat key ring already exists.
   2. Create a key in the key ring with the appropriate granularity for theresource type, unless such a key already exists.
   3. Create the per-project, per-service service account, unless that serviceaccount already exists.
   4. Grant the per-project, per-service service account encrypt and decryptpermissions on the key.
   5. Provide the key details to the developer so they can finish creating theresource.

3. With key details successfully returned by the Autokey serviceagent, the developer can immediately finish creating the protected resource.

Cloud KMS Autokey creates keys that have the attributes described in thenext section. This key creation flow preservesseparation of duties. The Cloud KMSadministrator continues to have full visibility and control over keys created byAutokey.

To start using Autokey after enabling it, seeCreate 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 orgranularity: Keys created by Autokey have a granularity that varies by resource type. For service-specific details about key granularity, seeCompatible 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 calledautokey 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 withkey 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, youcan do so by combining IAM access controls with CMEK organizationpolicies. This works by removing key creation permissions from principals otherthan the Autokey service agent, and then requiring that all resourcesare protected by CMEK using the Autokey key project. For detailedinstructions for enforcing the use of Autokey, seeEnforceAutokey usage.

Compatible services

The following table lists services that are compatible withCloud KMS Autokey:

Limitations

• The gcloud CLI is not available for Autokey resources.
• Key handles are not inCloud Asset Inventory.

What's next

• To get started with Cloud KMS Autokey, an administratormustenable Cloud KMS Autokey.
• To use Cloud KMS Autokey after it has been enabled, a developer cancreate CMEK-protected resources using Autokey.
• Learn aboutCMEK best practices.