[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-10 (世界標準時間)。"],[],[],null,["# Autokey overview\n\nCloud KMS Autokey simplifies creating and using [customer-managed encryption\nkeys (CMEKs)](/kms/docs/cmek) by automating provisioning and assignment. With\nAutokey, key rings and keys are generated on-demand. Service accounts\nthat use the keys to encrypt and decrypt resources are created and granted\nIdentity and Access Management (IAM) roles when needed. Cloud KMS administrators\nretain full control and visibility to keys created by Autokey, without\nneeding to pre-plan and create each resource.\n\nUsing keys generated by Autokey can help you consistently align with\nindustry standards and recommended practices for data security, including the\nHSM protection level, separation of duties, key rotation, location, and key\nspecificity. Autokey creates keys that follow both general guidelines\nand guidelines specific to the resource type for Google Cloud services\nthat integrate with Cloud KMS Autokey. After they are created, keys\nrequested using Autokey function identically to other\nCloud HSM keys with the same settings.\n\nAutokey can also simplify usage of Terraform for key management,\nremoving the need to run infrastructure-as-code with elevated key-creation\nprivileges.\n\nTo use Autokey, you must have an organization resource that contains\na folder resource. For more information about organization and folder resources,\nsee [Resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy).\n\nCloud KMS Autokey is available in all Google Cloud locations where\nCloud HSM is available. For more information about Cloud KMS\nlocations, see [Cloud KMS locations](/kms/docs/locations). There is no\nadditional cost to use Cloud KMS Autokey. Keys created using\nAutokey are priced the same as any other Cloud HSM keys. For\nmore information about pricing, see [Cloud Key Management Service pricing](/kms/pricing).\n\nHow Autokey works\n-----------------\n\nThis section explains how Cloud KMS Autokey works. The following user roles\nparticipate in this process:\n\nSecurity administrator\n: The security administrator is a user who is responsible\n for managing security at the folder or organization level.\n\nAutokey developer\n: The Autokey developer is a user who is\n responsible for creating resources using Cloud KMS Autokey.\n\nCloud KMS administrator\n: The Cloud KMS administrator is a\n user who is responsible for managing Cloud KMS resources. This role\n has fewer responsibilities when using Autokey than when using\n manually-created keys.\n\nThe following service agents also participate in this process:\n\nCloud KMS service agent\n: The service agent for Cloud KMS in a\n given key project. Autokey depends on this service agent having\n elevated privileges to create Cloud KMS keys and key rings and to\n set IAM policy on the keys, granting encrypt and decrypt\n permissions for each resource service agent.\n\nResource service agent\n: The service agent for a given service in a given\n resource project. This service agent must have encrypt and decrypt\n permissions on any Cloud KMS key before it can use that key for\n CMEK protection on a resource. Autokey creates the resource service\n agent when needed and grants it the necessary permissions to use the\n Cloud KMS key.\n\n### Security administrator enables Cloud KMS Autokey\n\nBefore you can use Autokey, the security administrator must complete\nthe following one-time setup tasks:\n\n1. Enable Cloud KMS Autokey on a resource folder and identify the\n Cloud KMS project that will contain Autokey resources for\n that folder.\n\n2. Create the Cloud KMS [service agent](/iam/docs/service-agents) and then grant\n key creation and assignment privileges to the service agent.\n\n3. Grant Autokey user roles to Autokey developer users.\n\nWith this configuration complete, Autokey developers can now trigger\nCloud HSM key creation on-demand. To see full setup instructions for\nCloud KMS Autokey, see [Enable Cloud KMS Autokey](/kms/docs/enable-autokey).\n\n### Autokey developers use Cloud KMS Autokey\n\nAfter Autokey is successfully set up, authorized Autokey\ndevelopers can now create resources protected using keys created for them\non demand. The details of the resource creation process depend on which resource\nyou are creating, but the process follows this flow:\n\n1. The Autokey developer begins to create a resource in a compatible\n Google Cloud service. During resource creation, the developer requests\n a new key from the Autokey service agent.\n\n2. The Autokey service agent receives the developer's request and\n completes the following steps:\n\n 1. Create a key ring in the key project at the selected location, unless that key ring already exists.\n 2. Create a key in the key ring with the appropriate granularity for the resource type, unless such a key already exists.\n 3. Create the per-project, per-service service account, unless that service account already exists.\n 4. Grant the per-project, per-service service account encrypt and decrypt permissions on the key.\n 5. Provide the key details to the developer so they can finish creating the resource.\n3. With key details successfully returned by the Autokey service\n agent, the developer can immediately finish creating the protected resource.\n\nCloud KMS Autokey creates keys that have the attributes described in the\nnext section. This key creation flow preserves\n[separation of duties](/kms/docs/separation-of-duties). The Cloud KMS\nadministrator continues to have full visibility and control over keys created by\nAutokey.\n\nTo start using Autokey after enabling it on a folder, see\n[Create protected resources using Cloud KMS Autokey](/kms/docs/create-resource-with-autokey).\n\nAbout keys created by Autokey\n-----------------------------\n\nKeys created by Cloud KMS Autokey have the following attributes:\n\n- **Protection level:** HSM.\n- **Algorithm:** AES-256 GCM.\n- **Rotation period:** One year.\n\n After a key is created by Autokey, a Cloud KMS\n administrator can edit the rotation period from the default.\n- **Separation of duties:**\n - The service account for the service is automatically granted encrypt and decrypt permissions on the key.\n - 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.\n - Autokey developers can only request key creation and assignment. They cannot view or manage keys.\n- **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](#compatible-services) on this page.\n- **Location:** Autokey creates keys in the same location as the\n resource to be protected.\n\n If you need to create CMEK-protected resources in locations where\n Cloud HSM is not available, you must create your CMEK manually.\n- **Key version state:** Newly created keys requested using Autokey are created as the primary key version in the enabled state.\n- **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.\n- **Key naming:** Keys created by Autokey follow this naming convention: \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`-`\u003cvar translate=\"no\"\u003eSERVICE_SHORT_NAME\u003c/var\u003e`-`\u003cvar translate=\"no\"\u003eRANDOM_HEX\u003c/var\u003e\n- **Key export:** Like all Cloud KMS keys, keys created by Autokey can't be exported.\n- **Key tracking:** Like all Cloud KMS keys used in CMEK integrated services that are compatible with [key tracking](/kms/docs/view-key-usage), keys created by Autokey are tracked in the Cloud KMS dashboard.\n\nEnforcing Autokey\n-----------------\n\nIf you want to enforce usage of Autokey within a folder, you can do so\nby combining IAM access controls with CMEK organization policies.\nThis works by removing key creation permissions from principals other than the\nAutokey service agent, and then requiring that all resources are\nprotected by CMEK using the Autokey key project. For detailed\ninstructions for enforcing the use of Autokey, see [Enforce\nAutokey usage](/kms/docs/enable-autokey#enforce-autokey).\n\nCompatible services\n-------------------\n\nThe following table lists services that are compatible with\nCloud KMS Autokey:\n\nLimitations\n-----------\n\n- The gcloud CLI is not available for Autokey resources.\n- Key handles are not in [Cloud Asset Inventory](/asset-inventory/docs/overview).\n\nWhat's next\n-----------\n\n- To get started with Cloud KMS Autokey, a security administrator must [enable Cloud KMS Autokey](/kms/docs/enable-autokey).\n- To use Cloud KMS Autokey after it has been enabled, a developer can [create CMEK-protected resources using Autokey](/kms/docs/create-resource-with-autokey).\n- Learn about [CMEK best practices](/kms/docs/cmek-best-practices)."]]
