Cloud KMS
Cloud KMS is the managed key service. Symmetric and asymmetric cryptographic keys, organized in key rings, with version history, scheduled rotation, and three tiers of where the key actually lives (software, dedicated HSM hardware, or outside Google entirely). The cryptographic operations — encrypt, decrypt, sign, verify — happen inside KMS; the key bytes never leave.
The mental model that pairs with the previous page: KMS holds keys that protect data. Secret Manager holds the data itself for secrets. KMS is how Google Cloud services do envelope encryption: your data is encrypted with a data encryption key (DEK), that DEK is encrypted with a key in KMS (the key encryption key, KEK), and only the KEK lives in KMS. Everything else — encrypted data, encrypted DEK — sits in your storage, useless without KMS access.
Managed Cryptographic Keys
Your dataplaintext objectKEK in Cloud KMSwraps the DEK; never leaves KMSKMS keys come in two main flavors. Symmetric keys use the same key to encrypt and decrypt — fastest, simplest, the right choice for most envelope encryption. Asymmetric keys have a public/private pair for signing and verification, or for encryption with the public key and decryption with the private key. Asymmetric keys are necessary when external parties need to verify signatures or encrypt data only you can decrypt; otherwise symmetric is the better default.
Key Hierarchy: Rings, Keys, Versions
Three layers of organization. A key ring is a regional container — a way to group related keys and bind IAM policies. A key lives inside a key ring; it carries metadata (purpose, rotation policy, IAM) and a stream of versions. A version is the actual cryptographic material; a key with rotation enabled accumulates versions over time. Versions can be enabled, disabled, or destroyed; older versions remain available for decrypting old data even as the primary version rotates forward.
Software, HSM, and External Tiers
Tiers rise in cost and assurance. Match the tier to a real compliance requirement, not to a vague sense that more is safer.
Three protection tiers, in increasing order of price and assurance:
- Software — Google manages the key in software at FIPS 140-2 Level 1 equivalent. Cheapest, sufficient for the vast majority of workloads.
- HSM — the key never exists outside a hardware security module at FIPS 140-2 Level 3. The right choice when a regulator or compliance regime explicitly requires HSM-backed keys, and not before — HSM keys cost noticeably more and the operational difference is invisible to the application.
- External Key Manager (Cloud EKM) — the key lives in your own HSM or third-party key manager (Fortanix, Futurex, Thales, etc.) outside Google entirely; GCP calls out to it for crypto operations. The right choice when sovereignty or "Google must not have access to the key" is a hard requirement, with significant operational and latency overhead.
CMEK Integration with GCP Services
Most GCP services that store data — BigQuery, Cloud Storage, Spanner, Persistent Disk, Cloud SQL, Pub/Sub, Compute Engine, and many more — support Customer-Managed Encryption Keys (CMEK). By default, Google encrypts data with Google-managed keys; CMEK lets you swap in a KMS key you control, with rotation policies you set, audit logs you see, and revocation power you hold. When CMEK access is revoked, the service can no longer decrypt — a real safeguard against insider risk and a real risk to availability if mismanaged.
KMS vs Secret Manager
The same comparison from the previous page, viewed from the KMS side.
Cloud KMS — cryptographic keys for envelope encryption and signing. The key bytes never leave KMS; you call KMS to encrypt or decrypt. Use it any time you want a service or application to encrypt data with a key under your control.
Secret Manager — the secret value itself. API keys, passwords, certificates. The application reads the value and uses it. Use it any time the credential is the data, not a tool for protecting other data.
Key Rotation and Destruction
Symmetric keys support automatic rotation on a schedule (commonly 90 days). A new version is generated and becomes the primary; the old versions stay around for decrypting data encrypted before the rotation. Rotation is cheap insurance — a long-lived primary key is exactly the kind of credential that ends up exposed by a future audit.
Destruction is asynchronous on purpose. When you destroy a key version, it enters a scheduled-for-destruction state with a grace period (default 30 days, configurable down to a 24-hour minimum). During the grace period you can restore the version. After the grace period, the key material is unrecoverable and any data encrypted with it becomes unrecoverable too. Set the grace period to match your worst-case "I accidentally destroyed the wrong key" recovery time — the 24-hour minimum is almost always too short.
- Using KMS to store secret values (passwords, API keys) by wrapping them in a key payload. KMS is for keys; Secret Manager is for secrets. Mixing them adds operational complexity without changing the security outcome.
- CMEK enabled on a production service with the underlying key managed by a team that doesn't rotate it, doesn't audit access, and doesn't know who depends on it. The compliance checkbox is ticked; the actual security outcome is no better than Google-managed keys.
- HSM tier chosen because "it sounds more secure" without a compliance requirement that actually mandates it. The price is real; the application-visible benefit is not.
- No automatic rotation set on symmetric keys. The same primary key encrypts production data for years.
- One master key reused across every environment, every data class, every service. A single key compromise blast radius is the entire org.
- Destruction grace period cut to the 24-hour minimum. The first accidental destruction that nobody notices within a day is permanent and silent.
- Automatic rotation enabled on symmetric keys. 90 days is a reasonable default; tune to your data class and compliance requirements.
- Separate keys per environment (dev, staging, prod) and per data class (PII, financial, public). One key compromise is one blast radius — keep them small.
- Software tier as the default. HSM only when compliance explicitly requires it. EKM only when sovereignty is a hard requirement.
- Key rings per project for clean blast-radius boundaries. Cross-project key sharing has its place but should be an explicit decision, not the default.
- Destruction grace period of at least 7 days, ideally 30. Accidental destruction is the worst kind of incident — give yourself a window.
- IAM bindings on key rings to limit who can use, manage, or destroy keys. The
cloudkms.cryptoKeyEncrypterDecrypterrole is what most workloads need — not the admin roles. - Cloud Audit Logs reviewed for key use patterns. Every encrypt and decrypt is logged; unusual patterns are an early signal of compromise.
Knowledge Check
What does envelope encryption mean in the context of Cloud KMS?
- Encrypting the same payload twice — once with a KMS key and once again with Secret Manager — to layer in defense in depth
- Encrypting data with a data encryption key (DEK), then encrypting the DEK with a key in KMS (the KEK); the KEK never leaves KMS, the encrypted data and encrypted DEK sit in your storage
- Encrypting structured JSON payloads only, since KMS keys are restricted to text-based input formats and cannot operate on raw binary data blobs at the individual byte level the way other tools can
- Wrapping an existing Secret Manager secret inside a KMS key payload before it is written to storage
When is the HSM tier the right choice over the Software tier?
- For essentially all production workloads across the board — HSM is now the modern recommended default tier and the older Software tier is gradually being phased out entirely
- When a compliance regime (e.g., FIPS 140-2 Level 3) explicitly requires HSM-backed keys; otherwise the application-visible benefit does not justify the cost
- For any workload that requires scheduled automatic key rotation, because the Software tier does not support any rotation feature at all and never has
- When the key will be used for asymmetric signing and verification operations, since only the HSM tier offers any form of asymmetric key support at all
What is the principal risk of cutting the key destruction grace period to its 24-hour minimum?
- Cloud KMS does not allow shortening the grace period below the 30-day default on any key
- An accidental destroy leaves only one day to notice and restore — after that, data encrypted with that key version is unrecoverable
- Shortening the grace period silently disables automatic scheduled rotation on that key
- Cloud KMS is forced to run a global cluster-wide reindex across all regions on every single key destruction that is configured with a minimum-length grace window
A team plans to "store all our secrets in KMS by wrapping them in a key payload". What is wrong?
- KMS payload size is capped at a hard 4 KB limit, and most real-world secrets are considerably larger than that
- KMS holds keys, not secret values — Secret Manager is the right tool for credential storage, with IAM, audit, and rotation designed for that purpose; wrapping a secret in a key adds steps without changing the outcome
- KMS audit logging cannot be enabled at all, so the wrapped secret values would be left with no usable access trail whatsoever
- Cloud KMS does not support symmetric keys at all; it offers only asymmetric signing keys, and an asymmetric key cannot be used to encrypt arbitrary secret values, so the whole wrapping approach is impossible from the start
What is Customer-Managed Encryption Keys (CMEK) in GCP services?
- A separate KMS product built specifically for AWS interoperability that lets AWS-managed services encrypt their data using Google-held keys
- Replacing the default Google-managed encryption keys with a KMS key you control — with your rotation policy, audit logs, and the ability to revoke access — for BigQuery, Cloud Storage, Spanner, and most other data services
- An automatic feature that generates and rotates a distinct per-customer encryption key for multi-tenant SaaS applications hosted on GCP
- A premium pricing tier of KMS that bundles HSM-backed keys together with a fully managed key rotation and audit service, sold as a paid upgrade over the standard software-tier offering aimed squarely at regulated enterprise customers
You got correct