100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
GCP

Cloud KMS Basics

An introduction to Google Cloud Key Management Service for creating, managing, and using encryption keys to protect data at rest.

Databases & IdentityIntermediate8 min readJul 10, 2026
Analogies

What Cloud KMS Manages

Cloud Key Management Service (KMS) is a centralized service for creating and managing cryptographic keys used to encrypt data, without ever exposing the raw key material to the applications that use it. Keys live inside a key ring (a regional grouping for organizational and access-control purposes), and each key can have multiple versions, since KMS supports automatic or manual key rotation while keeping older versions available to decrypt data that was encrypted before the rotation happened. Every GCP resource with data at rest, like a Persistent Disk, Cloud Storage bucket, or BigQuery table, is already encrypted by default with Google-managed keys, and Cloud KMS is what you reach for when you need customer-managed encryption keys (CMEK) to control rotation schedules, revoke access, or satisfy compliance requirements that mandate customer control over key material.

🏏

Cricket analogy: A key ring in Cloud KMS is like the BCCI's central vault holding every team's designated 'toss coin', with each key version like a specific coin used for a particular series, retired but kept on record for verifying past results.

Symmetric Keys, Asymmetric Keys, and Envelope Encryption

Cloud KMS supports symmetric keys (the same key encrypts and decrypts, used for most data-at-rest encryption via CMEK), asymmetric signing keys (for creating digital signatures verifiable with a public key, useful for code signing or JWT signing), and asymmetric encryption keys (public key encrypts, private key decrypts, useful when the encrypting party shouldn't have decryption rights). In practice, most large-scale encryption uses envelope encryption: KMS generates and protects a key-encryption-key (KEK) that never leaves KMS, while the application uses a locally generated data-encryption-key (DEK) to encrypt the actual bulk data, then asks KMS to encrypt (wrap) that DEK with the KEK for storage; decryption reverses the process by asking KMS to unwrap the DEK, then using it locally to decrypt the data, which avoids sending large payloads through the KMS API.

🏏

Cricket analogy: Envelope encryption is like a team using a specific match-day strategy sheet (the DEK) to plan each game, then locking that strategy sheet inside the coach's personal safe (the KEK) rather than sending every play call through team headquarters for direct approval.

Access Control, Rotation, and Destruction

Access to keys is governed by IAM roles scoped at the key ring or individual key level, such as roles/cloudkms.cryptoKeyEncrypterDecrypter (use the key without ever exporting it) versus roles/cloudkms.admin (manage the key's lifecycle, rotation schedule, and IAM policy), which lets you separate who can use a key from who can administer it. Automatic rotation can be scheduled (e.g., every 90 days) for symmetric keys, and Cloud KMS also supports a scheduled destruction workflow for key versions: requesting destruction starts a 24-hour (configurable) countdown during which the action can still be cancelled, after which the key version's material is permanently and irrecoverably deleted, making any data encrypted solely with that version permanently unreadable.

🏏

Cricket analogy: Separating encrypter/decrypter access from admin access is like letting a bowler use the ball during play without ever letting them decide the team's playing XI, a decision reserved for the captain and coach.

bash
# Create a key ring and a symmetric key with automatic 90-day rotation
gcloud kms keyrings create app-keyring --location=us-central1

gcloud kms keys create app-cmek \
  --keyring=app-keyring \
  --location=us-central1 \
  --purpose=encryption \
  --rotation-period=90d \
  --next-rotation-time=2026-10-08T00:00:00Z

# Grant a service account permission to use the key without managing it
gcloud kms keys add-iam-policy-binding app-cmek \
  --keyring=app-keyring \
  --location=us-central1 \
  --member="serviceAccount:app-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"

Cloud KMS integrates with Cloud HSM for FIPS 140-2 Level 3 validated hardware key protection, and with Cloud External Key Manager (EKM) for organizations that must keep key material outside Google's infrastructure entirely while still using GCP services.

Scheduled key version destruction is irreversible once the countdown completes; any data encrypted exclusively with that key version becomes permanently unrecoverable, so always verify no active data depends solely on a key version before confirming destruction.

  • Cloud KMS centrally manages cryptographic keys without exposing raw key material to applications.
  • Keys live in regional key rings and can have multiple versions to support rotation.
  • CMEK gives customers control over rotation, access, and revocation of encryption keys beyond Google-managed defaults.
  • Cloud KMS supports symmetric keys, asymmetric signing keys, and asymmetric encryption keys for different use cases.
  • Envelope encryption uses a KMS-protected KEK to wrap a locally generated DEK, avoiding large payloads through the KMS API.
  • IAM separates key usage (encrypter/decrypter) from key administration (rotation, policy management).
  • Key version destruction has a cancellable delay window but is permanent and irrecoverable once completed.

Practice what you learned

Was this page helpful?

Topics covered

#GCP#GCPFundamentalsStudyNotes#CloudComputing#CloudKMSBasics#Cloud#KMS#Manages#Symmetric#StudyNotes#SkillVeris