Cloud KMS in GCP Explained: Keys, IAM, Rotation, and CMEK

Cloud Key Management Service (Cloud KMS) is Google Cloud’s managed service for creating and controlling cryptographic keys. You define the keys, control who can use them via IAM, set rotation schedules, and choose whether key material lives in software or a hardware security module. Every key operation is recorded in audit logs. Cloud KMS is also the foundation for Customer-Managed Encryption Keys across GCP. When BigQuery, Cloud Storage, or Compute Engine uses a CMEK key, that key lives in Cloud KMS.

Why Cloud KMS matters

When data is encrypted, the key is the secret. If the people managing your data can also freely use the encryption keys, the access control model has a gap. Cloud KMS solves this by separating key administration from key use. A database administrator can manage data without having permission to export or disable the key that protects it. A service account can encrypt and decrypt without having permission to destroy key versions.

Cloud KMS also provides the audit trail that compliance frameworks require. Every encrypt, decrypt, and key management operation is recorded in Cloud Audit Logs. For regulated workloads, this makes it possible to demonstrate exactly who accessed what, and when.

Beyond compliance, Cloud KMS enables a key ownership model that default Google-managed encryption cannot provide. With default encryption, Google controls the key lifecycle. With Cloud KMS, you can disable a key version and immediately make data inaccessible. That capability matters during incident response or offboarding.

How Cloud KMS works

Cloud KMS uses envelope encryption, which is the same model GCP services use internally. Here is the sequence:

  1. Your application or a GCP service needs to store encrypted data.
  2. A unique data encryption key (DEK) is generated for that object.
  3. The object is encrypted with the DEK.
  4. Cloud KMS encrypts (wraps) the DEK using your key. This wrapped DEK is stored alongside the encrypted data.
  5. To read the data, the service asks Cloud KMS to unwrap the DEK, then decrypts the object.

IAM controls who can ask Cloud KMS to wrap or unwrap keys. Audit logs record every request. When you rotate a key, new DEKs are wrapped with the new key version going forward. Existing wrapped DEKs remain readable using the old version until you disable or destroy it.

For a full explanation of envelope encryption and how GCP applies it across storage services, see Encryption in Google Cloud.

When to use Cloud KMS

Cloud KMS is the right choice when you need control over the key lifecycle that default Google-managed encryption cannot provide. Common scenarios:

  • CMEK for GCP services. BigQuery, Cloud Storage, Compute Engine persistent disks, Cloud SQL, Pub/Sub, and others support Customer-Managed Encryption Keys. You create the key in Cloud KMS, grant the service agent permission to use it, and the service encrypts all data using your key rather than a Google-managed one.

  • Separation of duties. When key administrators and workload owners need to be different identities, for example a security team controls keys while product teams own data. Cloud KMS IAM makes this separation enforceable.

  • Compliance and audit requirements. Regulations such as PCI-DSS, ISO 27001, and certain government frameworks require demonstrable control over encryption keys and an audit trail of cryptographic operations. Cloud KMS provides both.

  • Key revocation during incidents. Disabling a key version immediately makes all data wrapped with it inaccessible without deleting the data. This is a standard incident response capability for regulated environments.

  • HSM or external key management. For workloads requiring FIPS 140-2 Level 3 certification, or where key material must reside outside Google infrastructure entirely, Cloud KMS supports HSM and Cloud External Key Manager (EKM) protection levels.

  • Digital signatures. Asymmetric keys in Cloud KMS can sign and verify data. This is used for JWT signing, code signing, and Binary Authorization attestations.

When Cloud KMS may not be necessary

Default Google-managed encryption is strong. GCP encrypts all data at rest with AES-256 by default, at no cost, with no configuration required. If your workload does not require key ownership, audit trails of decrypt operations, or the ability to revoke access by disabling a key, default encryption is the right choice.

Operational cost

Adding Cloud KMS introduces real overhead. Keys can be misconfigured, rotation must be monitored, and a key incident can make production data inaccessible. Apply CMEK where the compliance or security requirement actually justifies it, not everywhere by default.

Cloud KMS resource hierarchy

Cloud KMS organises resources in a three-level hierarchy: key rings contain crypto keys, and crypto keys contain key versions.

Key rings

A key ring is a container for crypto keys, bound to a specific GCP location (regional, multi-regional, or global). The location determines where key material is stored and processed, which matters for data residency and CMEK compatibility. A Cloud Storage bucket in europe-west2 must use a KMS key in europe-west2 or a compatible multi-region location.

A common pattern is one key ring per application per environment: payments-prod, payments-staging, analytics-prod.

IAM bindings set on a key ring apply to all keys inside it. Bindings set on an individual key apply only to that key and take precedence for that resource.

Key rings cannot be deleted

Once created, a key ring persists indefinitely even if all keys inside it are disabled or destroyed. Plan your key ring structure before you create them. You cannot rename or move a key ring after the fact.

Crypto keys

A crypto key is the named key object within a key ring. It defines the purpose (what the key does), the protection level (how the key material is stored), and the rotation schedule (how often a new key version is created automatically). The crypto key itself does not contain raw key material; that lives in key versions.

Key versions

Each key version is an immutable set of key material. When you rotate a key, a new key version is created and becomes the primary. The previous primary version remains in the ENABLED state and can still decrypt data encrypted with it.

Destroying a key version is irreversible

Any data encrypted solely with a destroyed key version becomes permanently unrecoverable. GCP enforces a minimum 24-hour scheduled deletion window, giving you time to cancel if a version was marked for destruction by mistake. After the window closes, recovery is impossible.

Key purposes and protection levels

Key purposes

A key’s purpose determines which cryptographic operations it supports. You set the purpose when creating the key and cannot change it afterwards:

  • ENCRYPT_DECRYPT uses symmetric AES-256-GCM encryption and decryption. This is the purpose used for CMEK on GCP services and for direct application encryption via the KMS API.

  • ASYMMETRIC_SIGN creates and verifies digital signatures using RSA or EC keys. Used for code signing, JWT signing, and Binary Authorization attestations.

  • ASYMMETRIC_DECRYPT supports asymmetric encryption and decryption using RSA. Used when you need public key encryption, for example encrypting data client-side with a public key that only Cloud KMS can decrypt.

  • MAC produces message authentication codes using HMAC. Used to verify data integrity without encryption.

Protection levels

The protection level determines how and where key material is stored and used:

  • SOFTWARE performs key operations in Google-managed software. Lower cost per operation. Appropriate for the majority of workloads.

  • HSM performs key operations exclusively within a FIPS 140-2 Level 3 certified Hardware Security Module. The key material never leaves the HSM in plaintext. Required for workloads with strict regulatory requirements such as PCI-DSS or certain government certifications. Higher cost than SOFTWARE.

  • EXTERNAL / EXTERNAL_VPC keeps key material in your own external key manager via Cloud External Key Manager (EKM). Use this when policy or regulation requires the key to reside entirely outside Google infrastructure.

IAM roles for Cloud KMS

Cloud KMS deliberately separates the ability to manage keys from the ability to use them. This is the core of its security model. Someone who can both administer keys and perform cryptographic operations has no effective check on their behaviour. The roles are designed to prevent that:

  • roles/cloudkms.admin gives full control over key rings and keys, including creating keys, updating rotation schedules, and scheduling key version destruction. It does not allow performing cryptographic operations (encrypt/decrypt). Assign to security operations teams, not to application service accounts.

  • roles/cloudkms.cryptoKeyEncrypterDecrypter allows encrypting and decrypting data using the key. It does not allow managing key metadata, versions, or policies. This is the role granted to GCP service agents when configuring CMEK. For example, the BigQuery service agent needs this role on your Cloud KMS key.

  • roles/cloudkms.cryptoKeyEncrypter is encrypt-only. Useful for write-only data pipelines where the application should never be able to read back what it wrote.

  • roles/cloudkms.cryptoKeyDecrypter is decrypt-only.

  • roles/cloudkms.viewer reads key metadata but allows no cryptographic operations and no key management.

Grant at the key level, not the key ring

Granting roles/cloudkms.cryptoKeyEncrypterDecrypter on a key ring gives the identity access to every key inside it. Grant it on the individual key where you can. For background on scoping IAM bindings correctly, see Least Privilege in GCP and IAM Policies.

When configuring CMEK, the service agent (not your personal account) needs the encrypter/decrypter role. Service agents are Google-managed service accounts that GCP creates automatically for each service in your project.

Key rotation

Cloud KMS supports automatic rotation for symmetric keys. You set a rotation period on the crypto key, and KMS automatically creates a new primary key version on that schedule. Common rotation periods are 90 days or 180 days for data encryption keys.

Rotation does not re-encrypt existing data

The new primary version is used for all new encryption operations. Data encrypted with older key versions remains encrypted with those versions. Old versions stay ENABLED so they can still decrypt existing data. If you need data re-encrypted under the new key version, you must do that explicitly as a separate operation.

What rotation does limit is forward exposure. After a rotation, new data is protected by the new key version. If an older key version is later compromised, only data encrypted with that version is at risk. Over time, as old data ages out of retention, you can disable and eventually destroy old key versions, but only after verifying no active workload still depends on them.

If you are rotating secrets stored in Secret Manager rather than keys themselves, see Rotating Secrets Automatically.

Creating and managing keys

The examples below cover the most common Cloud KMS operations using gcloud.

# Create a key ring in a specific region
gcloud kms keyrings create prod-app-ring \
  --location=europe-west2 \
  --project=my-app-prod

# Create a symmetric encryption key with automatic 90-day rotation
gcloud kms keys create app-data-key \
  --location=europe-west2 \
  --keyring=prod-app-ring \
  --purpose=encryption \
  --rotation-period=7776000s \
  --next-rotation-time=2026-06-01T00:00:00Z \
  --project=my-app-prod

# Create an HSM-protected key for higher-compliance workloads
gcloud kms keys create payment-data-key \
  --location=europe-west2 \
  --keyring=prod-app-ring \
  --purpose=encryption \
  --protection-level=hsm \
  --project=my-app-prod

# Grant a service account encrypt/decrypt access to a specific key
gcloud kms keys add-iam-policy-binding app-data-key \
  --location=europe-west2 \
  --keyring=prod-app-ring \
  --member="serviceAccount:api-server@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" \
  --project=my-app-prod

# List all key versions and their states
gcloud kms keys versions list \
  --key=app-data-key \
  --keyring=prod-app-ring \
  --location=europe-west2 \
  --project=my-app-prod

# Schedule a key version for destruction (24-hour minimum delay)
gcloud kms keys versions destroy 1 \
  --key=app-data-key \
  --keyring=prod-app-ring \
  --location=europe-west2 \
  --project=my-app-prod
Location compatibility

The key location must be compatible with the GCP service using it. A BigQuery dataset in europe-west2 must use a CMEK key in europe-west2 or a multi-region location that includes it. A mismatch often surfaces as a cryptic permission error rather than a location error, which makes it hard to diagnose.

Cloud KMS vs Secret Manager

These two services are related but solve different problems. Confusing them is common when starting with GCP security.

  • Cloud KMS manages cryptographic key material. It stores keys, performs encrypt and decrypt operations, handles rotation, and enforces IAM on key access. It does not store application secrets.

  • Secret Manager stores sensitive configuration values: database passwords, API keys, TLS certificates, and OAuth tokens. It versions secrets, controls access with IAM, and logs every secret access event. It does not perform encryption operations directly.

The two often work together. Secret Manager encrypts secret versions at rest using Cloud KMS. If you configure CMEK on a Secret Manager secret, the encryption key lives in Cloud KMS and you control its lifecycle. Disabling the KMS key version makes the secret inaccessible without deleting it.

Practical rule of thumb

If you need to store a database password or API key that your application reads at runtime, use Secret Manager. If you need to encrypt data objects, sign artefacts, or control the key a GCP service uses to encrypt its storage, use Cloud KMS.

Cloud KMS vs CMEK

Cloud KMS is a service. CMEK (Customer-Managed Encryption Keys) is a pattern, and Cloud KMS is how you implement it.

When a GCP service such as BigQuery, Cloud Storage, or Compute Engine supports CMEK, it means you can configure the service to use a key you control in Cloud KMS instead of a Google-managed key. The service handles the encryption; it just calls Cloud KMS to wrap and unwrap the data encryption keys using the key you specify.

Cloud KMS is the vault. CMEK is the decision to use your vault instead of Google’s. You can use Cloud KMS without CMEK (for application-level encryption via the KMS API), and you cannot implement CMEK without Cloud KMS.

For a step-by-step guide to configuring CMEK on specific GCP services, see Customer-Managed Encryption Keys (CMEK).

Common beginner mistakes

  1. Using one key for unrelated systems. A single encryption key covering your database, object storage, and backup archives means a key incident or compromise affects all three simultaneously. Use separate keys per application, per environment, and per data sensitivity level. Key rings are free, and key organisation is a security control in itself.

  2. Granting admin and use permissions to the same identity. The separation between roles/cloudkms.admin and roles/cloudkms.cryptoKeyEncrypterDecrypter is intentional. An identity that can both manage key versions and perform cryptographic operations has no accountability boundary. Keep key administration limited to a small number of identities with strict audit log monitoring.

  3. Assuming rotation re-encrypts existing data. Key rotation creates a new primary key version and uses it for future encryptions. It does not touch data encrypted with older versions. If you need data re-encrypted under the new key version, you must do that explicitly as a separate operation.

  4. Destroying a key version without checking dependencies. Destroying a key version is permanent. Any data encrypted solely with that version becomes unrecoverable. Before scheduling a version for destruction, audit every service, dataset, and secret that references the key. The 24-hour window exists for this reason. Use it.

  5. Ignoring key location compatibility. A key in us-central1 cannot be used as a CMEK key for a resource in europe-west2. Plan key locations before creating key rings, because key rings cannot be moved or deleted once created.

  6. Not monitoring audit logs for key operations. Bulk decrypt calls, unexpected key version disables, and IAM policy changes on high-value keys are all signals worth alerting on. Treat key operations with the same monitoring priority as any other privileged action in your project.

Related topics to read next

These pages build directly on what you have just read.

  • Encryption in Google Cloud covers envelope encryption, the difference between GMEK, CMEK, and CSEK, and when each level is appropriate.
  • Customer-Managed Encryption Keys (CMEK) shows how to configure CMEK on BigQuery, Cloud Storage, and Compute Engine using Cloud KMS keys.
  • Secret Manager explains how to store and access application secrets, and how Secret Manager can use Cloud KMS as its encryption backend.
  • Rotating Secrets Automatically covers automating rotation of secrets stored in Secret Manager.
  • Cloud Audit Logs explains how to monitor key operations and cryptographic activity through GCP audit logging.
  • IAM Roles in GCP provides background on how IAM roles work, including predefined roles like the Cloud KMS roles covered here.
  • Least Privilege in GCP covers how to scope IAM bindings correctly, including on Cloud KMS key resources.
  • Service Accounts explains the identities that typically hold Cloud KMS encrypter/decrypter roles in production workloads.

Frequently asked questions

What is Cloud KMS in GCP?

Cloud Key Management Service (Cloud KMS) is Google Cloud's managed service for creating, storing, and controlling cryptographic keys. You create symmetric AES-256 keys or asymmetric RSA and EC keys, configure automatic rotation, and control access using IAM. Keys can be used directly via the KMS API, or as Customer-Managed Encryption Keys (CMEK) for services like BigQuery, Cloud Storage, and Compute Engine.

What is a key ring in Cloud KMS?

A key ring is a permanent container for cryptographic keys, bound to a specific GCP location. Key rings cannot be deleted once created. Only the keys inside them can be disabled or destroyed. The key ring location determines where key material is stored and processed, which matters for data residency and CMEK compatibility. IAM bindings on a key ring apply to all keys inside it, while bindings on individual keys apply only to that key.

What is the difference between Cloud KMS and Secret Manager?

Cloud KMS manages cryptographic keys used for encryption and decryption operations. Secret Manager stores application secrets such as API keys, passwords, and certificates. They solve different problems: Cloud KMS handles key material, Secret Manager handles configuration secrets. The two often work together. Secret Manager can use Cloud KMS as the encryption backend for secret versions when CMEK is configured.

Does key rotation re-encrypt existing data?

No. Rotation in Cloud KMS creates a new primary key version and uses it for all new encryption operations going forward. Data encrypted with an older key version remains encrypted with that version. The old version stays enabled so it can still be used to decrypt existing data. Rotation limits future exposure and does not retroactively re-encrypt stored data.

When should I use HSM keys instead of software keys?

Use HSM protection when your workload has regulatory requirements such as PCI-DSS, FIPS 140-2 Level 3 compliance, or government certification standards. HSM stores and processes key material exclusively within a certified hardware module and the key never leaves the HSM in plaintext. HSM keys cost more per operation than software keys. For most standard cloud workloads, software protection is appropriate.

Last verified: 22 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.