How to Configure Google Cloud Key Management Service (KMS) External Key Manager (EKM)

In highly regulated industries like financial services and defense, compliance frameworks often mandate that cryptographic keys used to encrypt data in the cloud must never physically reside within the cloud provider’s infrastructure.

While Google Cloud KMS Customer-Managed Encryption Keys (CMEK) give you control over the key lifecycle, the actual AES material is generated and stored inside Google’s Hardware Security Modules (HSMs). For institutions requiring absolute cryptographic sovereignty, this is unacceptable. They must maintain the keys on their own on-premises HSMs (like Thales or Entrust) while still leveraging cloud services like BigQuery and Cloud Storage.

The solution is Google Cloud External Key Manager (EKM). EKM allows you to use keys hosted in your on-premises data center (or a third-party key broker) to encrypt data in Google Cloud. When BigQuery needs to decrypt a row of data, it makes a secure, real-time API call out of Google Cloud, across the internet (or an Interconnect), to your on-premises HSM. Your HSM decrypts the Data Encryption Key (DEK) and returns it to GCP.

This guide explains how to architect and configure Google Cloud EKM for absolute data sovereignty.

Understanding the EKM Architecture

EKM relies on envelope encryption, but shifts the root of trust outside of Google.

1. Data Encryption Key (DEK): Google Cloud generates an ephemeral DEK to encrypt your actual data (e.g., a file in Cloud Storage).
2. Key Encryption Key (KEK): This is the master key. It lives exclusively on your on-premises HSM.
3. The Encryption Flow: Google Cloud sends the plaintext DEK via a secure gRPC API call to your on-premises EKM provider. Your HSM encrypts the DEK using the KEK and sends the ciphertext back to Google. Google stores the encrypted DEK alongside your data.
4. The Decryption Flow: When a user requests the data, Google Cloud sends the encrypted DEK to your on-premises EKM. Your HSM decrypts it and returns the plaintext DEK. Google uses the DEK in memory to decrypt the data, and then instantly destroys the DEK from RAM.

The Ultimate Kill Switch: If you detect a breach, you simply disable the KEK on your on-premises HSM. Google Cloud instantly loses the ability to decrypt any data, rendering the cloud ciphertext mathematically useless, regardless of Google’s internal access.

Step 1: Deploying the EKM Provider

Google Cloud does not speak directly to the proprietary hardware protocols of a Thales HSM. You must deploy an EKM Provider application (acting as a translation proxy) in your data center.

Many vendors (Thales, Fortanix, HashiCorp Vault) provide pre-built EKM proxy servers. This proxy must be exposed to the internet via a highly available HTTPS endpoint (e.g., https://ekm.internalcorp.com) secured with a publicly trusted TLS certificate.

Step 2: Configuring the EKM Connection in Google Cloud

To securely route the cryptographic requests to your data center, you must configure an EKM connection in GCP.

1. Navigate to the Google Cloud Console.
2. Go to Security > Key Management.
3. Click on the EKM Connections tab and click Create Connection.
4. Name: on-prem-hsm-connection
5. Service Directory: You must configure a Service Directory endpoint. This ensures that GCP routes the traffic reliably to your EKM provider’s URI (https://ekm.internalcorp.com).
6. Authentication: Google Cloud uses an OIDC service account to authenticate to your EKM provider. You must configure your EKM provider to trust the OIDC tokens generated by this specific GCP service account, ensuring that only your GCP project can request cryptographic operations from your HSM.

Step 3: Creating the External Key in Cloud KMS

Once the connection is established, you represent your on-premises key as a resource inside Google Cloud KMS.

First, create a standard Key Ring in Cloud KMS (e.g., global-ekm-keyring).

Next, use the gcloud CLI to create the External Key. You must specify the exact URI of the key as defined by your EKM provider (the Key URI).

gcloud kms keys create on-prem-master-key \
    --keyring=global-ekm-keyring \
    --location=global \
    --purpose=encryption \
    --protection-level=external \
    --ekm-connection=on-prem-hsm-connection \
    --key-uri="https://ekm.internalcorp.com/v0/keys/12345678-abcd"

Notice the --protection-level=external flag. This explicitly tells Google Cloud that the key material does not reside within Google’s infrastructure.

Step 4: Using the External Key with Google Cloud Services

You can now use this external key exactly like a standard CMEK key across Google Cloud.

For example, to create a BigQuery dataset that is cryptographically tethered to your on-premises HSM:

bq mk --dataset \
    --default_kms_key="projects/my-project/locations/global/keyRings/global-ekm-keyring/cryptoKeys/on-prem-master-key" \
    my_project:highly_regulated_dataset

Architectural Considerations and Latency

Deploying EKM introduces two significant architectural constraints:

1. Latency: Every cryptographic operation requires a round-trip network call from Google Cloud to your data center. If your EKM provider is slow, or your network connection is saturated, your BigQuery queries and Cloud Storage reads will suffer massive latency penalties. It is highly recommended to use Google Cloud Interconnect to minimize this delay.
2. Availability: Your EKM provider is now a Tier-0 critical dependency. If your data center loses power or internet connectivity, your entire Google Cloud environment will instantly go offline because GCP cannot decrypt the data. You must deploy your EKM providers in a highly available, multi-region architecture.

Conclusion

Google Cloud External Key Manager (EKM) provides the ultimate cryptographic separation of duties. By physically isolating the root key material within on-premises Hardware Security Modules, enterprises can adopt the massive analytical scale of BigQuery and Cloud Storage while maintaining absolute, mathematically provable data sovereignty, satisfying the most draconian regulatory frameworks on the planet.