How to Configure Google Cloud Key Management Service (KMS) External Key Manager (EKM) for On-Premises Cryptography

When enterprises migrate highly sensitive workloads to the public cloud, the primary regulatory hurdle is often key sovereignty. In a standard Google Cloud architecture, data at rest is encrypted using keys generated and stored inside Google Cloud Key Management Service (KMS). While Google provides robust access controls, the fundamental truth remains: the cryptographic key physically resides on Google’s silicon.

For strictly regulated industries—such as European financial institutions bound by Schrems II, or defense contractors dealing with export-controlled data—storing the decryption key in the same cloud environment as the encrypted data is legally impermissible. They require absolute, mathematical proof that Google cannot decrypt their data under a foreign subpoena.

Google solved this architectural constraint with Cloud KMS External Key Manager (EKM).

EKM fundamentally severs the cryptographic tie. With EKM, the encryption keys are generated and stored in a physical Hardware Security Module (HSM) sitting inside your own on-premises data center (or at a trusted third-party vendor like Thales or Fortanix). When a Google Cloud service (like BigQuery) needs to decrypt data, it must establish a mutually authenticated TLS connection across the internet, reach into your basement, and ask your physical HSM to perform the decryption operation. The raw key material never enters the Google Cloud network.

This guide explains how to architect and configure Google Cloud KMS EKM.

Understanding the EKM Architecture

The EKM architecture relies on a strict API contract between Google and your hardware:

1. The External Key: You generate an AES-256 wrapping key inside your on-premises HSM. This key is marked as non-exportable.
2. The EKM Provider: You run an EKM software appliance (provided by your HSM vendor) that acts as an API bridge between Google Cloud and your physical HSM.
3. The Google Cloud KMS Link: You create an “External Key” reference in Google Cloud KMS. This is not a key; it is merely a URI pointing to your EKM provider’s public IP address.
4. The Cryptographic Operation: When BigQuery reads a table, it sends the encrypted ciphertext to Google KMS. Google KMS sends the ciphertext over the internet to your EKM provider. Your HSM decrypts it, and the EKM provider sends the plaintext back to BigQuery.

Step 1: Preparing the On-Premises EKM Provider

Before configuring Google Cloud, your on-premises infrastructure must be ready.

1. Deploy your HSM (e.g., Thales Luna Network HSM) and ensure the EKM proxy software is running.
2. The EKM proxy must be accessible from the internet (or via a dedicated Google Cloud Interconnect).
3. You must configure mTLS (Mutual TLS). The EKM proxy must possess a server certificate issued by a public CA, and you must configure it to explicitly trust the Google Cloud KMS client certificates.
4. Generate a symmetric key inside the HSM and copy the Key URI (e.g., v1/some-unique-key-id).

Step 2: Configuring the Google Cloud EKM Connection

With your on-premises infrastructure listening, you must instruct Google Cloud how to connect to it.

This requires configuring an EKM Connection at the Google Cloud project level. You can do this via the Google Cloud Console GUI, or via the gcloud CLI.

gcloud kms ekm-connections create my-onprem-hsm \
    --location=us-central1 \
    --service-directory-service="projects/my-project/locations/us-central1/namespaces/default/services/my-hsm" \
    --hostname="ekm.mycompany.com" \
    --certificate-file="public_cert_of_ekm.pem"

(Note: The certificate-file is the public certificate of your EKM proxy. Google KMS pins this certificate to ensure it is not subjected to a Man-in-the-Middle attack when connecting back to your data center).

Step 3: Creating the External Key in Cloud KMS

Now that the secure pipeline is established, you create the logical key reference in Cloud KMS.

Create a Key Ring in the specific region (EKM does not support global key rings):

gcloud kms keyrings create my-ekm-keyring --location=us-central1

Create the External Key, linking it to the URI provided by your HSM:

gcloud kms keys create my-sovereign-key \
    --location=us-central1 \
    --keyring=my-ekm-keyring \
    --purpose=encryption \
    --protection-level=external \
    --ekm-connection-key-path="v1/some-unique-key-id" \
    --ekm-connection="my-onprem-hsm"

The --protection-level=external flag is the critical parameter. It explicitly tells Google KMS that it does not own the cryptographic material for this key.

Step 4: Utilizing the Sovereign Key

The architectural beauty of EKM is that from the perspective of Google Cloud services, an External Key functions exactly like a native Google-managed key.

To encrypt a highly sensitive BigQuery dataset using your on-premises HSM, you simply assign the KMS key URI when creating the dataset.

bq mk \
--encryption_service_account=service-1234567890@gcp-sa-bigquery.iam.gserviceaccount.com \
--default_kms_key="projects/my-project/locations/us-central1/keyRings/my-ekm-keyring/cryptoKeys/my-sovereign-key" \
my_secure_dataset

When you query that dataset, you will see the latency of the query increase slightly. This is the physical reality of data sovereignty: for every encrypted block, BigQuery is waiting for a cryptographic response from the physical HSM sitting in your basement.

Step 5: The Ultimate Kill Switch

The true power of EKM is the “Kill Switch.”

If your Security Operations Center (SOC) detects a massive compromise of your Google Cloud environment, you do not need to rely on Google API calls to revoke IAM access (which an attacker might have bypassed).

You simply pull the physical network cable out of the back of your EKM proxy in your data center. Instantly, all read and write operations across your entire Google Cloud environment that rely on that key will fail with cryptographic hard stops. The cloud data is mathematically reduced to random noise until you plug the cable back in.

Conclusion

Cloud KMS External Key Manager (EKM) bridges the gap between the infinite scalability of public cloud compute and the rigid compliance demands of absolute data sovereignty. By forcing Google Cloud to traverse a mutually authenticated mTLS tunnel to execute cryptographic operations on an on-premises Hardware Security Module, enterprise architects guarantee that they retain exclusive, physical possession of the ultimate decryption authority.