This page provides an overview of Cloud External Key Manager (Cloud EKM).

Terminology

• External key manager (EKM)

  The key manager used outside of Google Cloud to manage your keys.

• Cloud External Key Manager (Cloud EKM)

  A Google Cloud service for using your external keys that are managed within a supported EKM.

• Cloud EKM through the internet

  A version of Cloud EKM where Google Cloud communicates with your external key manager over the internet.

• Cloud EKM through a VPC

  A version of Cloud EKM where Google Cloud communicates with your external key manager over a Virtual Private Cloud (VPC). For more information, seeVPC network overview.

• EKM key management fromCloud KMS

  When using Cloud EKM through a VPC with an external key management partner that supports the Cloud EKM control plane, you can use theCloud KMS EKM management mode to simplify the process of maintaining external keys in your external key management partner and in Cloud EKM. For more information, seeCoordinated external keys andEKM key management fromCloud KMS on this page.

• Crypto space

  A container for your resources within your external key management partner. Your crypto space is identified by a unique crypto space path. The format of the crypto space path varies by external key management partner—for example,v0/cryptospaces/YOUR_UNIQUE_PATH.

• Partner-managed EKM

  An arrangement where your EKM is managed for you by a trusted partner. For more information, seePartner-managed EKM on this page.

• Key Access Justifications

  When you use Cloud EKM with Key Access Justifications, each request to your external key management partner includes a field that identifies the reason for each request. You can configure your external key management partner to allow or deny requests based on the Key Access Justifications code provided. For more information about Key Access Justifications, see Key Access Justifications overview.

Overview

With Cloud EKM, you can use keys that you manage within asupported external key management partner to protect data withinGoogle Cloud. You can protect data at rest insupported CMEK integrationservices, or by calling the Cloud Key Management Service API directly.

Cloud EKM provides several benefits:

• Key provenance: You control the location and distribution of yourexternally managed keys. Externally managed keys are never cached or storedwithin Google Cloud. Instead, Cloud EKM communicates directlywith the external key management partner for each request.

• Access control: You manage access to your externally managed keys inyour external key manager. You can't use an externally managed key inGoogle Cloud without first granting the Google Cloud projectaccess to the key in your external key manager. You can revoke this accessat any time.

• Centralized key management: You can manage your keys and access policiesfrom a single user interface, whether the data they protect resides in thecloud or on your premises.

In all cases, the key resides on the external system, and is never sent toGoogle.

You can communicate with your external key managerover theinternet orover aVirtual Private Cloud (VPC).

How Cloud EKM works

Cloud EKM key versions consist of these parts:

• External key material: The external key material of a Cloud EKMkey is cryptographic material created and stored in your EKM. This materialdoes not leave your EKM and it is never shared with Google.
• Key reference: Each Cloud EKM key version contains either a keyURI or a key path. This is a unique identifier for the external key materialthat Cloud EKM uses when requesting cryptographic operations usingthe key.
• Internal key material: When a symmetric Cloud EKM key iscreated, Cloud KMS creates additional key material inCloud KMS, which never leaves Cloud KMS. This key materialis used as an extra layer of encryption when communicating with your EKM.This internal key material does not apply to asymmetric signing keys.

To use your Cloud EKM keys, Cloud EKM sends requests forcryptographic operations to your EKM. For example, to encrypt data with asymmetric encryption key, Cloud EKM first encrypts the data using theinternal key material. The encrypted data is included in a request to the EKM.The EKM wraps the encrypted data in another layer of encryption using theexternal key material, and then returns the resulting ciphertext. Data encryptedusing a Cloud EKM key can't be decrypted without both the external keymaterial and the internal key material.

If your organization has enabled Key Access Justifications, your external key management partnerrecords the provided access justification and completes the request onlyforjustification reason codes that are allowed by yourKey Access Justifications policy on the external key management partner.

Creating and managing Cloud EKM keys requires corresponding changes inboth Cloud KMS and the EKM.These corresponding changes are handled differently formanually managedexternal keys and forcoordinated external keys. All external keys accessed over theinternet are manually managed. External keys accessed over a VPC network can bemanually managed or coordinated, depending on the EKM management mode of the EKMconnection. TheManual EKM management mode is used for manuallymanaged keys. TheCloud KMS EKM management mode is used for coordinated external keys.For more information about EKM management modes, seeManually managed externalkeys andCoordinated external keyson this page.

The following diagram shows how Cloud KMS fits into the key managementmodel. This diagram uses Compute Engine and BigQuery as two examples;you can also seethe full list of services that support Cloud EKMkeys.

Caution: Both the Cloud EKM key version and the external key arerequired for each encryption and decryption request. If you lose access toeither key, your data cannot be recovered. It is not possible to re-create anidentical Cloud EKM key version by using the same external key URI orkey path.

You can learn about theconsiderations andrestrictions when using Cloud EKM.

Manually managed external keys

This section provides a broad overview of how Cloud EKM works with amanually managed external key.

1. You create or use an existing key in asupported external key management partnersystem. This key has a unique URI or key path.
2. You grant your Google Cloud project access to use the key,in the external key management partner system.
3. In your Google Cloud project, you create a Cloud EKM keyversion, using the URI or key path for the externally managed key.
4. Maintenance operations like key rotation must be manually managed betweenyour EKM and Cloud EKM. For example, key version rotation orkey version destruction operations need to be completed both directly inyour EKM and in Cloud KMS.

Within Google Cloud, the key appears alongside your otherCloud KMS and Cloud HSM keys, with protection levelEXTERNAL orEXTERNAL_VPC. The Cloud EKM key and theexternal key management partner key work together to protect your data. The external keymaterial is never exposed to Google.

Coordinated external keys

This section provides an overview of how Cloud EKM works withcoordinated external keys.

1. Youset up an EKM connection,setting theEKM management mode toCloud KMS. During setup, youmust authorize your EKM to access your VPC network and authorize yourGoogle Cloud project service account to access yourcrypto space inyour EKM. Your EKM connection uses the hostname of your EKM and acryptospace path that identifies your resources within your EKM.

2. Youcreate an external key inCloud KMS. When you create a Cloud EKM key using an EKMover VPC connection with theCloud KMS EKM management mode enabled, thefollowing steps take place automatically:

   1. Cloud EKM sends a key creation request to your EKM.
   2. Your EKM creates the requested key material. This external key materialremains in the EKM and is never sent to Google.
   3. Your EKM returns a key path to Cloud EKM.
   4. Cloud EKM creates your Cloud EKM key version using thekey path provided by your EKM.

3. Maintenance operations on coordinated external keys can be initiated fromCloud KMS. For example, coordinated external keys used forsymmetric encryption can be automatically rotated on a set schedule. Thecreation of new key versions is coordinated in your EKM byCloud EKM. You can also trigger the creation or destruction ofkey versions in your EKM from Cloud KMS using theGoogle Cloud console, the gcloud CLI, the Cloud KMSAPI, or Cloud KMS client libraries.

Within Google Cloud, the key appears alongside your otherCloud KMS and Cloud HSM keys, with protection levelEXTERNAL_VPC. The Cloud EKM key and the external key management partner key worktogether to protect your data. The external key material is never exposed toGoogle.

EKM key management fromCloud KMS

Coordinated external keys are made possible by EKM connections that use EKM key management fromCloud KMS.If your EKM supports the Cloud EKMcontrol plane, then you can enable EKM key management fromCloud KMS for yourEKM connections to create coordinated external keys. With EKM key management fromCloud KMS enabled,Cloud EKM can request the following changes in your EKM:

• Create a key: When you create an externally managed key inCloud KMS using a compatible EKM connection,Cloud EKM sends your key creation request to your EKM. Whensuccessful, your EKM creates the new key and key material and returns thekey path for Cloud EKM to use to access the key.

• Rotate a key: When you rotate an externally-managed key inCloud KMS using a compatible EKM connection,Cloud EKM sends your rotation request to your EKM. When successful,your EKM creates new key material and returns the key path forCloud EKM to use to access the new key version.

• Destroy a key: When you destroy a key version for an externally-managed keyin Cloud KMS using a compatible EKM connection,Cloud KMS schedules the key version for destruction inCloud KMS. If the key version is not restored before thescheduledfor destruction period ends, Cloud EKM destroys its part of thekey's cryptographic material and sends a destruction request to your EKM.

  Data encrypted with this key version cannot be decrypted after the keyversion is destroyed in Cloud KMS, even if the EKM has not yetdestroyed the key version. You can see whether the EKM has successfullydestroyed the key version by viewing the key's details inCloud KMS.

When keys in your EKM are managed from Cloud KMS, the key materialstill resides in your EKM. Google can't make any key management requests to yourEKM without explicit permission.Google can't change permissions or Key Access Justifications policies in yourexternal key management partner system.If you revoke Google's permissions in your EKM, key management operationsattempted in Cloud KMS fail.

Compatibility

Supported key managers

You can store external keys in the following external key management partner systems:

• Supported today:
  • Fortanix
  • Futurex
  • Thales

Services that support CMEK with Cloud EKM

The following services support integration with Cloud KMS forexternal (Cloud EKM) keys:

• Agent Assist
• AlloyDB for PostgreSQL
• Apigee API hub
• Application Integration
• Artifact Registry
• Backup for GKE
• BigQuery
• Bigtable
• Cloud Composer
• Cloud Data Fusion
• Cloud Healthcare API
• Cloud Logging:Data in the Log Router andData in Logging storage
• Cloud Run
• Cloud Run functions
• Cloud SQL
• Cloud Storage
• Cloud Tasks
• Cloud Workstations
• Compute Engine:Persistent disks,Snapshots,Custom images, andMachine images
• Conversational Insights
• Database Migration Service:MySQL migrations - data written to databases,PostgreSQL migrations - Data written to databases,PostgreSQL to AlloyDB migrations - Data written to databases,SQL Server migrations - Data written to databases, andOracle to PostgreSQL data at rest
• Dataflow
• Dataform
• Dataplex Universal Catalog
• Dataproc:Dataproc clusters data on VM disks andDataproc serverless data on VM disks
• Dataproc Metastore
• Datastream
• Dialogflow CX
• Document AI
• Eventarc Advanced (Preview)
• Eventarc Standard
• Filestore
• Firestore
• Google Cloud Managed Service for Apache Kafka
• Google Cloud NetApp Volumes
• Google Distributed Cloud
• Google Kubernetes Engine:Data on VM disks andApplication-layer secrets
• Integration Connectors
• Looker (Google Cloud core)
• Memorystore for Redis
• Memorystore for Redis Cluster
• Memorystore for Valkey
• Migrate to Virtual Machines:Data migrated from VMware, AWS, and Azure VM sources andData migrated from disk and machine image sources
• Parameter Manager
• Pub/Sub
• Secret Manager
• Secure Source Manager
• Spanner
• Speaker ID (Restricted GA)
• Speech-to-Text
• Vertex AI
• Vertex AI Workbench instances
• Workflows
• Workload Manager

Important: All other services are not compatible with Cloud External Key Manager for CMEK.Note: If your Cloud EKM key is not listed in the Google Cloud consolewhen setting up CMEK services, firstcopy the resourcename.Then selectDon't see your key? Enter key resource name. and enter the keyresource name captured earlier.

Considerations

• When you use a Cloud EKM key, Google has no control over theavailability of your externally managed key in the external key management partner system.If you lose keys that you manage outside of Google Cloud, Google can'trecover your data.

• Review the guidelines aboutexternal key management partners and regions whenchoosing the locations for your Cloud EKM keys.

• Review theCloud EKM Service Level Agreement(SLA).

• Communicating with an external service over the internet can lead toproblems with reliability, availability, and latency. For applications withlow tolerance for these types of risks, consider using Cloud HSM orCloud KMS to store your key material.

  • If an external key is unavailable, Cloud KMS returns aFAILED_PRECONDITION error and provides details in thePreconditionFailureerror detail.

    Enable data audit logging to maintain a record of allerrors related to Cloud EKM. Error messages contain detailedinformation to help pinpoint the source of the error. An example of acommon error is when an external key management partner does not respond to a requestwithin a reasonable timeframe.

  • You need a support contract with the external key management partner.Google Cloud support can only help with issues inGoogle Cloud services and cannot directly assist with issues onexternal systems. Sometimes, you must work with support on both sides totroubleshoot interoperability issues.

• Cloud EKM can be used withBare Metal Rack HSM to create a single-tenantHSM solution integrated with Cloud KMS. To learn more, choose aCloud EKM partner that supports single-tenant HSMs and review therequirements for Bare Metal Rack HSMs.

• Enable audit logging in your external key manager to capture access andusage to your EKM keys.

Caution: When you use Cloud EKM keys, there's a risk that the key canbecome unavailable. Depending on which services you're using, this can causefatal errors or inaccessible data. For example, if you use an external CMEK keyto encrypt Google Kubernetes Engine application-layer secrets, your nodes can becomeunavailable if they can't decrypt the secrets. Inability to access the externalkey can also cause permanent data loss. For example, if the CMEK key used toencrypt a Spanner database remains unavailable for more than 30consecutive days, Spannerautomatically deletes the database. When the current key version is notavailable, you cannot recover the data by rotating to a new key version. Forbetter availability, consider using Cloud EKM over VPC orCloud HSM keys.

Restrictions

• When you create a Cloud EKM key using the API or theGoogle Cloud CLI, it must not have an initial key version. This does notapply to Cloud EKM keys created using theGoogle Cloud console.
• Automatic rotation is not supported for manually-managed externalkeys.
• Cloud EKM operations are subject tospecificquotasin addition to the quotas on Cloud KMS operations.

Symmetric encryption keys

• Symmetric encryption keys are only supported for the following:
  • Customer managed encryption keys (CMEK) insupported integrationservices.
  • Symmetric encryption and decryption using Cloud KMSdirectly.
• Data that is encrypted by Cloud EKM using an externally managed keycannot be decrypted without using Cloud EKM.

Asymmetric signing keys

• Asymmetric signing keys are limited to a subset of Cloud KMSalgorithms.
• Asymmetric signing keys are only supported for the following use cases:
  • Asymmetric signing using Cloud KMSdirectly.
  • Custom signing key withAccess Approval.
• Once an asymmetric signing algorithm is set on a Cloud EKM key, itcannot be modified.
• Signing must be done on thedata field.

External key managers and regions

Cloud EKM needs to be able to reach your keys quickly toavoid an error. When creating a Cloud EKM key, choose aGoogle Cloud location that is geographically near the location of theexternal key management partner key. See your external key management partner's documentation to determinewhich locations they support.

• Cloud EKM over the internet: available in most Google Cloudlocations where Cloud KMS is available, including regional andmulti-regional locations.
• Cloud EKM over a VPC: available in mostregionallocations where Cloud KMS isavailable. Cloud EKM over a VPC isn't available inmulti-regional locations.

Some locations includingglobal andnam-eur-asia1 aren't available forCloud EKM. To learn which locations support Cloud EKM, seeCloud KMS locations.

Multi-region use

When you use an externally managed key with a multi-region, the metadata of thekey is available in multiple data centers within the multi-region. This metadataincludes the information needed to communicate with the external key management partner. If yourapplication fails over from one data center to another within the multi-region,the new data center initiates key requests. The new data center may havedifferent network characteristics from the previous data center, includingdistance from the external key management partner and the likelihood of timeouts. We recommendonly using a multi-region with Cloud EKM if your chosen external keymanager provides low latency to all areas of that multi-region.

Partner-managed EKM

Partner-managed EKM lets you use Cloud EKM through a trusted sovereignpartner that manages your EKM system for you. With partner-managed EKM, yourpartner creates and manages the keys that youuse in Cloud EKM. The partner ensures that your EKM complies withsovereignty requirements.

When you onboard with your sovereign partner, the partner provisions resourcesin the Google Cloud and your EKM. These resources include aCloud KMS project to manage your Cloud EKM keys and an EKMconnection configured for EKM key management fromCloud KMS. Your partner creates resourcesin Google Cloud locations according to your data residency requirements.

Each Cloud EKM key includesCloud KMS metadata, which lets Cloud EKM send requests to yourEKM to perform cryptographic operations using the external key material thatnever leaves your EKM. Symmetric Cloud EKM keys also includeCloud KMS internal key material that never leaves Google Cloud.For more information about the internal and external sides of Cloud EKMkeys, seeHow Cloud EKM works on this page.

For more information about partner-managed EKM, seeConfigure partner-managedCloud KMS.

Monitor Cloud EKM usage

Preview

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.

You can use Cloud Monitoring to monitor your EKM connection. The followingmetrics can help you understand your EKM usage:

• cloudkms.googleapis.com/ekm/external/request_latencies
• cloudkms.googleapis.com/ekm/external/request_count

For more information about these metrics, seecloudkms metrics. You can create adashboard to track these metrics. To learn how to set up a dashboard to monitoryour EKM connection, seeMonitor EKM usage.

Getting support

If you experience an issue with Cloud EKM, contactSupport.

What's next

• Startusing theAPI.

• Set up Cloud EKM over theinternet.

• Create an EKM connection to use EKM overVPC.

• Read through theCloud KMS APIReference.

• Learn aboutLogging in Cloud KMS. Logging is basedon operations, and applies to keys with both HSM and software protectionlevels.

• SeeReference architectures for reliable deployment of Cloud EKMservices for recommendations on configuring an External KeyManager (EKM) service deployment integratedwith Cloud EKM.