How to Deploy Google Cloud Key Management Service (KMS) External Key Manager (EKM) for Hold-Your-Own-Key (HYOK)

When migrating highly sensitive workloads to the cloud—such as European financial records subject to Schrems II, or classified defense data—standard encryption is often insufficient for regulators. By default, Google Cloud encrypts data at rest using Google-managed encryption keys. If you use Customer-Managed Encryption Keys (CMEK), you generate the keys, but the cryptographic material still resides inside Google’s Cloud KMS hardware security modules (HSMs).

For organizations operating under the strictest geopolitical mandates, even allowing Google to host the key material is a violation. They require Hold-Your-Own-Key (HYOK).

Google Cloud achieves this via Cloud KMS External Key Manager (EKM). With EKM, the actual cryptographic keys never leave your physical, on-premises data center (or a trusted third-party HSM like Thales or Fortanix). When a Google Cloud service (like BigQuery or Cloud Storage) needs to decrypt data, it must make a real-time API call over a secure network to your on-premises EKM to perform the cryptographic operation.

This guide explains the architecture of Cloud EKM and how to configure a connection between Google Cloud and an external key manager.

Understanding Cloud KMS EKM Architecture

The EKM architecture relies on a fundamental separation of duties:

1. Data Storage: The encrypted ciphertext (e.g., a BigQuery table) resides in Google Cloud.
2. Key Material: The cryptographic key (the Data Encryption Key, or DEK) resides in your on-premises HSM.
3. The Cryptographic Operation: When BigQuery needs to read the data, it contacts Google Cloud KMS. Cloud KMS acts as a proxy, securely reaching out to your on-premises EKM over an IPsec VPN or Cloud Interconnect.
4. The Payload: Cloud KMS sends the encrypted DEK to your EKM. Your EKM decrypts it inside your physical hardware and sends the plain-text DEK back to BigQuery (in RAM only).

The Kill Switch: The most powerful feature of EKM is absolute control. If you detect a breach, or a regulator demands data lockdown, you simply turn off your on-premises EKM server. Instantly, all your data in Google Cloud becomes mathematically inaccessible, even to Google engineers, because the keys required to decrypt it physically do not exist in the cloud.

Step 1: Setting up the EKM Network Connection

Because EKM requires Google Cloud KMS to reach into your network, you must establish a secure network path. This is typically done via VPC Network Peering or Private Service Connect.

If your EKM is hosted on-premises, you must have a highly available Cloud Interconnect or Cloud VPN terminating in a GCP VPC. You then use Serverless VPC Access or an Internal TCP Load Balancer to route the traffic from Cloud KMS to your on-premises EKM IP address.

Step 2: Configuring the External Key Manager

Your external key manager (e.g., Thales CipherTrust, Fortanix DSM, or HashiCorp Vault) must support the specific EKM API protocol mandated by Google.

Within your EKM software, you must create a specific key ring and key, and then generate an EKM URI. This URI tells Google Cloud exactly how to route the cryptographic requests.

A typical EKM URI looks like this:

https://ekm.internalcorp.com/v0/ekms/endpoints/gcp-kms/keys/my-hyok-key

Step 3: Creating the EKM Connection in Google Cloud

Now, you must configure Google Cloud KMS to trust and communicate with your EKM.

Using the gcloud CLI, create the EKM connection. This requires providing the hostname of your EKM, the path to the EKM’s TLS certificate (so Google can verify it’s talking to the right server), and the Service Directory endpoint if you are using private routing.

gcloud kms ekm-connections create internalcorp-ekm \
    --location=global \
    --service-directory-service=projects/my-project/locations/global/namespaces/ekm-namespace/services/ekm-service \
    --server-certificates-files=./ekm-server-cert.pem \
    --crypto-space-path="my-hyok-key"

Step 4: Creating the External Key in Cloud KMS

Once the connection is established, you create a representation of the key within Cloud KMS. This is the object that Google Cloud services (like GCS) will interact with.

First, create a KeyRing in Cloud KMS (if you haven’t already):

gcloud kms keyrings create hyok-keyring --location=global

Now, create the External Key, linking it to the EKM URI you generated from your on-premises software:

gcloud kms keys create my-external-key \
    --location=global \
    --keyring=hyok-keyring \
    --protection-level=external \
    --ekm-connection-key-path="https://ekm.internalcorp.com/v0/ekms/endpoints/gcp-kms/keys/my-hyok-key"

The --protection-level=external flag is the critical parameter. It instructs Google Cloud that this key is an EKM key and the cryptographic operations must be proxied off-cloud.

Step 5: Encrypting Cloud Resources with the EKM Key

You can now use this external key exactly like a standard Customer-Managed Encryption Key (CMEK).

For example, to create a highly classified Google Cloud Storage bucket protected by your on-premises EKM key:

gcloud storage buckets create gs://classified-data-bucket-001 \
    --location=eu \
    --default-encryption-key=projects/my-project/locations/global/keyRings/hyok-keyring/cryptoKeys/my-external-key

Conclusion

Google Cloud KMS External Key Manager represents the ultimate paradigm in cloud data sovereignty. By retaining absolute physical custody of cryptographic key material in on-premises hardware, enterprise security teams can confidently migrate the most sensitive, highly regulated datasets to the cloud, possessing a verifiable, instantaneous cryptographic kill switch.