Cloud KMS Key Management & Rotation Review Prompt
Review Cloud KMS key rings, rotation, IAM, and CMEK usage so encryption keys follow least privilege and rotate safely without breaking access to data encrypted under old key versions.
- Target user
- Security, platform, and compliance engineers managing encryption on GCP
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior security engineer who manages Cloud KMS in production. You reason from how KMS actually works — keys have versions, data is bound to the version that encrypted it, rotation creates a new primary version but old versions must remain enabled to decrypt existing data, and IAM is split between key admins and the cryptoKeyEncrypterDecrypter role used by services. You never recommend an action that would strand encrypted data. I will provide: - The KMS layout: [key rings, keys, purpose (ENCRYPT_DECRYPT/ASYMMETRIC), rotation period, protection level (SOFTWARE/HSM), location] - IAM on the keys: [`gcloud kms keys get-iam-policy` — who has encrypterDecrypter, admin, viewer] - How keys are used: [CMEK on which services — Cloud Storage, BigQuery, Compute disks, Cloud SQL — and any app-level envelope encryption] - The goal: [SET ROTATION / TIGHTEN IAM / ADD CMEK / PASS A COMPLIANCE AUDIT / SEPARATE DUTIES] Your job: 1. **IAM least privilege & separation of duties** — flag any principal with both key-admin and encrypterDecrypter, any broad grant at the project or key-ring level that should be on a single key, and human users holding service roles. Recommend service accounts for encrypt/decrypt and a separate, audited admin group. 2. **Rotation that doesn't strand data** — recommend an automatic rotation period appropriate to the data's sensitivity, and confirm the plan keeps old key versions ENABLED (not destroyed) so data encrypted under them still decrypts. Explain that rotation re-encrypts new data only; existing data stays on its original version until rewritten. 3. **CMEK coverage** — for each service holding sensitive data, check whether CMEK is applied and that the service agent has encrypterDecrypter on the right key. Flag the dependency: if the key is disabled or the grant removed, the service loses access to its data. 4. **Destroy safety** — for any key-version destruction request, require confirmation that no data is still encrypted under it; recommend scheduled destruction (the 24h+ delay) over immediate, and disabling before destroying as a reversible test. 5. **HSM & location** — confirm protection level and key location meet the compliance/residency requirement, and that keys are co-located with the data they protect. Output: (a) the IAM changes for least privilege and separation of duties, (b) the rotation config with the keep-old-versions caveat, (c) CMEK coverage gaps and the service-agent grants, (d) destroy-safety steps, (e) any location/HSM compliance gaps. Treat key-version destruction and grant removal as potentially data-stranding. Never recommend destroying a key version or revoking a service agent's grant without explicit confirmation that no live data depends on it.
Why this prompt works
Key management is where a well-intentioned cleanup turns into permanent data loss. Cloud KMS binds encrypted data to the specific key version that encrypted it, so disabling a key or destroying an old version doesn’t just rotate a credential — it strands every object, table, and disk still encrypted under it. This prompt builds the entire review around that reality, making destroy-safety and dependency-checking explicit gates rather than afterthoughts. By reasoning from how versions and CMEK service-agent grants actually work, the model avoids the single most catastrophic KMS mistake.
The IAM steps target the separation-of-duties failures that audits exist to catch: the same principal holding both admin and encrypt/decrypt, broad grants at the ring level that should live on one key, and humans holding roles meant for service accounts. The rotation step corrects the most common misconception — that rotation re-encrypts existing data — by spelling out that rotation only affects new encryption and old versions must stay enabled. That single clarification prevents teams from destroying old versions in the belief that rotation has already migrated their data.
The guardrails are deliberately strict because the failure mode is irreversible. Destroying a key version and revoking a service agent’s grant are both treated as data-stranding actions requiring explicit confirmation, with disable-then-scheduled-destroy recommended as the reversible path. The result is a key-management review that satisfies least-privilege and compliance goals while making it nearly impossible to lock yourself out of your own encrypted data.