Customer-Managed Encryption Keys (CMEK) in Google Cloud Explained

Simple explanation

Underneath this, Google Cloud uses a technique called envelope encryption. Your KMS key does not directly encrypt every byte of data. Instead, the service generates a unique per-object key (the data encryption key, or DEK), and uses your KMS key to lock that DEK away. To read data, the service calls Cloud KMS to unlock the DEK, then decrypts the actual data. If your KMS key is disabled, the DEK stays locked, and the data stays unreadable.

What are customer-managed encryption keys in Google Cloud?

CMEK is a feature available in many Google Cloud services that lets you designate your own Cloud KMS key as the encryption key for data at rest. Without CMEK, each service uses a Google-managed key that is rotated and controlled entirely by Google, with no visibility or control on your side.

With CMEK, your Cloud KMS key is the authority. Every time the service needs to read or write protected data, it must use your key to call Cloud KMS and wrap or unwrap the data encryption key. If your key is disabled, Cloud KMS rejects the call and the data becomes inaccessible immediately, regardless of what IAM permissions a principal holds on the resource itself.

This distinction matters: CMEK controls decryption, not just storage. It adds a second access gate that sits outside of standard resource-level IAM. An identity can have full IAM access to a BigQuery dataset and still be unable to read any data if the CMEK key is disabled.

CMEK keys live in Cloud KMS, where you create them, set rotation schedules, and control access via IAM. The underlying encryption model is the same AES-256 envelope encryption that Google uses for all data at rest. CMEK gives you ownership of the top-level key, not a different algorithm.

Why CMEK matters

With Google-managed encryption, Google controls the keys. You cannot see when they are rotated, who can access them, or how to revoke data access independently of IAM. For many workloads this is perfectly acceptable. For regulated industries (financial services, healthcare, government) compliance requirements often demand that you can demonstrate customer control over encryption keys.

CMEK provides two capabilities that Google-managed keys do not:

• Revocable access: disabling your CMEK key version makes the data it protects immediately inaccessible, even to Google. This is a meaningful control for data sovereignty requirements and emergency lockout scenarios. Re-enabling the key version restores access.

• Per-operation audit trail: every encrypt and decrypt call made using your CMEK key is recorded in Cloud Audit Logs with the calling identity, resource, and timestamp. Google-managed keys do not provide this.

CMEK vs Google-managed keys vs CSEK

Google Cloud supports three encryption key models for data at rest. The right choice depends on how much control you need and how much operational complexity you are prepared to take on. See Encryption in Google Cloud for a full breakdown of the underlying model.

CSEK requires you to supply raw key material with each API request, meaning you are responsible for key storage, delivery, and rotation entirely outside of GCP. Most regulated workloads use CMEK rather than CSEK because Cloud KMS handles key storage and rotation securely with far less operational overhead.

How CMEK works

CMEK uses envelope encryption. Your Cloud KMS key is the key encryption key (KEK). It does not directly encrypt bulk data. Instead, the service generates a unique data encryption key (DEK) for each object or record, encrypts the data with the DEK, then calls Cloud KMS to wrap (encrypt) the DEK with your KEK. Only the wrapped DEK is stored alongside the ciphertext.

Here is the full flow, step by step:

1. You create a key ring and symmetric encryption key in Cloud KMS and grant the relevant service agent access to it.
2. You configure a resource (a Cloud Storage bucket, BigQuery dataset, or Compute Engine disk) to use your CMEK key.
3. When the service writes data, it generates a per-object DEK, encrypts the data with it, then calls Cloud KMS to wrap the DEK using your KEK. The wrapped DEK is stored with the object.
4. Cloud KMS checks whether the calling service agent has roles/cloudkms.cryptoKeyEncrypterDecrypter before performing the wrap. Every call is recorded in Cloud Audit Logs.
5. When the service reads data, it calls Cloud KMS to unwrap the DEK, then decrypts the object in memory. This call is also logged.
6. If your key is disabled, step 5 fails. Cloud KMS rejects the unwrap call and the data is inaccessible to everyone, including identities with full IAM access to the resource.

Re-enabling the key version restores access for new read requests immediately. The underlying data and wrapped DEKs are unchanged.

Service agents and permissions

A service agent is a Google-managed service account that a GCP service uses to perform operations on your behalf, including calling Cloud KMS to wrap and unwrap data keys. Each service has its own service agent identity. You must grant it roles/cloudkms.cryptoKeyEncrypterDecrypter on your CMEK key before the service can use CMEK.

Service agent email formats by service:

• Cloud Storage: service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com
• BigQuery: bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com
• Compute Engine: service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com
• Cloud Run: service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com

Service agent IAM checklist

When to use this

CMEK is the right choice when you need verifiable, independent control over data access that goes beyond what standard IAM provides. Use it when:

• Your workload is subject to regulatory requirements (PCI-DSS, HIPAA, ISO 27001, FedRAMP) that demand demonstrable customer control over encryption keys.
• Your security team or auditors require a per-operation audit trail of all encryption and decryption activity, which Google-managed keys do not provide.
• You need to revoke all data access independently of IAM. For example, to isolate a compromised environment, terminate a third-party contract, or respond to a data breach investigation.
• You are separating key management duties from resource administration. The team running BigQuery should not necessarily control the encryption keys for regulated datasets.
• You are designing for data sovereignty and need to demonstrate that key material is controlled in a specific location, separately from Google’s infrastructure management.

When CMEK is not the right choice

CMEK adds real operational responsibility. It is not the right default for every workload. Avoid it when:

• You are building a prototype, dev environment, or low-risk workload. The extra key management overhead is not worth the added risk of accidental lockouts or misconfiguration at this stage.

• Your team has no established key management process. CMEK without clear ownership, rotation policies, and recovery procedures adds risk rather than reducing it. Set up the process before enabling the feature.

• The service or region you need does not support CMEK. Not every service supports it, and CMEK keys must be in the same location as the resources they protect. Verify support before designing around it.

• You are choosing CMEK purely because it sounds more secure. If there is no specific regulatory or business requirement driving the decision, Google-managed encryption is already strong. CMEK is about control and auditability, not a stronger encryption algorithm.

• You have not planned for key failure scenarios. If a key is accidentally disabled, every workload using it stops immediately. Enabling CMEK without a tested recovery procedure creates a new single point of failure.

Common use cases

CMEK is most commonly applied to storage and data services that hold sensitive or regulated information:

• BigQuery datasets containing financial records, health data, or personal data that feeds compliance-audited reports. With CMEK, you can prove to auditors that only your key unlocks query access, and that you can terminate that access independently of dataset IAM.

• Cloud Storage buckets storing regulated documents: contracts, medical records, financial statements, or backups. See Cloud Storage security for related access controls that complement CMEK.

• Cloud SQL instances and Compute Engine persistent disks for PCI-DSS or HIPAA in-scope workloads where the database layer needs demonstrable encryption key control.

• Secret Manager for high-sensitivity secrets (API keys, signing certificates, database passwords) where you want key control on top of the default Google-managed encryption layer.

• CI/CD pipelines handling regulated secrets, where secrets stored in CMEK-protected Secret Manager are accessed at build or deploy time. See secrets in CI/CD pipelines for that pattern.

Configuring CMEK

Prerequisites

Before running any CMEK configuration commands, confirm all of the following:

• Cloud KMS key ring created in the correct location (must match your service resource location)
• Symmetric encryption key created in that key ring
• Target service confirmed to support CMEK in your chosen region
• Service agent email identified for your project and service
• roles/cloudkms.cryptoKeyEncrypterDecrypter granted to the service agent on your key
• Key rotation schedule set
• Test plan written for key disablement and re-enablement before going live

# Step 1: Create a key ring and key in the correct location
gcloud kms keyrings create prod-cmek-ring \
  --location=europe-west2 \
  --project=my-app-prod

gcloud kms keys create bigquery-key \
  --location=europe-west2 \
  --keyring=prod-cmek-ring \
  --purpose=encryption \
  --project=my-app-prod

# Step 2: Get the BigQuery service agent for the project
PROJECT_NUMBER=$(gcloud projects describe my-app-prod --format='value(projectNumber)')
BQ_SA="bq-${PROJECT_NUMBER}@bigquery-encryption.iam.gserviceaccount.com"

# Step 3: Grant the service agent access to the key
gcloud kms keys add-iam-policy-binding bigquery-key \
  --location=europe-west2 \
  --keyring=prod-cmek-ring \
  --member="serviceAccount:${BQ_SA}" \
  --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" \
  --project=my-app-prod

# Step 4: Create a BigQuery dataset using CMEK
bq mk \
  --dataset \
  --default_kms_key="projects/my-app-prod/locations/europe-west2/keyRings/prod-cmek-ring/cryptoKeys/bigquery-key" \
  my-app-prod:sensitive_dataset

# Configure a Cloud Storage bucket to use CMEK
gcloud storage buckets update gs://my-app-prod-sensitive \
  --default-encryption-key=projects/my-app-prod/locations/europe-west2/keyRings/prod-cmek-ring/cryptoKeys/storage-key

# Disable a key version (makes data inaccessible but reversible)
gcloud kms keys versions disable 1 \
  --key=bigquery-key \
  --keyring=prod-cmek-ring \
  --location=europe-west2 \
  --project=my-app-prod

# Re-enable the key version to restore access
gcloud kms keys versions enable 1 \
  --key=bigquery-key \
  --keyring=prod-cmek-ring \
  --location=europe-west2 \
  --project=my-app-prod

Before you enable CMEK in production

Enabling CMEK without adequate preparation is one of the most common sources of production incidents in cloud security programmes. Work through this checklist before rolling out CMEK to any production workload:

• Verify key location compatibility. The KMS key must be in the same location as the resource it protects. A multi-region key in us cannot protect a resource in us-east1.
• Set an automatic rotation schedule. Keys without rotation schedules are a compliance gap in most frameworks. Configure rotation in Cloud KMS when you create the key.
• Define key ownership clearly. Document who can create, disable, and destroy key versions. This should be a small, controlled group, separate from the team running the data services.
• Define and test your break-glass process. If the key is accidentally disabled, who gets paged, who can re-enable it, and how quickly? Write this down and rehearse it before going live.
• Measure recovery time. Re-enabling a key version does not instantly restore all workloads. Measure how long affected services take to resume normally after a key is re-enabled.
• Test CMEK in a non-production environment first. Enable CMEK on staging, simulate key disablement, and confirm that your monitoring and alerting fires correctly.
• Check whether existing data will be re-encrypted automatically. It usually will not be. Existing Cloud Storage objects and BigQuery tables are not migrated automatically. Plan for this explicitly.
• Create a migration plan for existing data. If full CMEK coverage is required, you must copy existing objects or recreate tables with the CMEK key specified.
• Validate service and region support. Confirm that every service and resource type in your design supports CMEK in the specific regions you are using.

CMEK support across services

CMEK is supported by the most commonly used GCP storage and data services, but not all services support it. Support also varies by resource type within a service, and by region. Always verify current service documentation before building a CMEK-dependent architecture.

• Cloud Storage (per-bucket default key)
• BigQuery (per-dataset default key; individual tables can use different keys)
• Compute Engine persistent disks (key specified at disk creation)
• Cloud SQL (key specified when creating the instance)
• GKE (for boot disks and persistent volume claims)
• Cloud Run (for container image storage)
• Pub/Sub (per-topic key)
• Artifact Registry (per-repository key)
• Cloud Spanner (per-instance key)

Secret Manager also supports CMEK for at-rest protection of secret values, extending your key control strategy to application secrets and credentials.

Enforcing CMEK with Organisation Policy

The Organisation Policy constraint constraints/gcp.restrictNonCmekServices prevents resources from being created in listed services unless a valid CMEK key is specified. This makes CMEK a hard requirement rather than a best-effort guideline for sensitive environments.

Enforcing this constraint at the folder or project level (rather than the entire organisation) is the safer starting point. Some services or regions do not support CMEK, and a broad org-level constraint can block legitimate workloads if not scoped carefully. Test the constraint in a single project before rolling it out further.

# policy.yaml — restrict BigQuery and Cloud Storage to require CMEK
# name: projects/my-app-prod/policies/gcp.restrictNonCmekServices
# spec:
#   rules:
#   - values:
#       allowedValues:
#       - bigquery.googleapis.com
#       - storage.googleapis.com

gcloud org-policies set-policy policy.yaml

Pair this constraint with Restricting Resource Locations if data residency is also a requirement. CMEK alone does not control where data is physically stored.