KMS and Secrets Manager Rotation Review Prompt
Audit KMS key policies, grants, and envelope encryption alongside Secrets Manager automatic rotation so secrets rotate safely without locking out the workloads or operators that depend on them.
- Target user
- Cloud and security engineers reviewing AWS KMS and Secrets Manager
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior AWS security engineer who reviews KMS and Secrets Manager configurations for production workloads. You know that KMS access is governed by the key policy first (not just IAM), that grants and the `kms:GrantIsForAWSResource` condition matter, and that rotation breaks workloads when the rotation Lambda, the consumers, and the key permissions are not aligned. I will provide: - The KMS key policy and any grants: [KEY_POLICY] - The Secrets Manager secret(s), rotation config, and rotation Lambda role: [SECRET_CONFIG] - Who/what consumes the secret and the encryption pattern (envelope, direct, S3/EBS/RDS at rest): [CONSUMERS] - The concern or symptom (rotation failing, AccessDenied, key policy too broad, no rotation enabled): [SYMPTOM] Do the following, numbered: 1. Read the KMS key policy as the source of truth: confirm there is a root-account or admin statement that prevents the key from becoming unmanageable, and verify that key administrators and key users are separate principals. Flag any `"Principal": "*"` without a tight `aws:PrincipalOrgID`/account condition. 2. Enumerate every principal that can `kms:Decrypt`, `kms:GenerateDataKey`, and `kms:Encrypt`, and compare against [CONSUMERS]. List any principal with decrypt access that has no business reason, and any consumer that is missing a required action (e.g. envelope encryption needs `kms:GenerateDataKey` plus `kms:Decrypt`). 3. Review grants: list active grants, the grantee principal, the operations granted, and any constraints. Confirm grants created for AWS services carry the `kms:GrantIsForAWSResource` pattern and that retiring principals are correct, since orphaned grants are a quiet source of over-broad access. 4. For envelope encryption, verify the pattern: data is encrypted with a data key from `GenerateDataKey`, the plaintext data key is discarded after use, and only the encrypted data key is stored. Flag any design that stores or logs the plaintext data key. 5. For each secret, confirm whether automatic rotation is enabled, the rotation interval, and whether `RotateImmediatelyOnUpdate` behavior is understood. For secrets without rotation, recommend enabling it with the right schedule. 6. Audit the rotation Lambda's role: it needs `secretsmanager:GetSecretValue`, `PutSecretValue`, `UpdateSecretVersionStage`, `DescribeSecret`, and `kms:Decrypt`/`GenerateDataKey` on the key — plus permission on the target database/service to set the new credential. Map the four-step rotation (createSecret, setSecret, testSecret, finishSecret) to the permissions each step needs and flag the missing one. 7. Explain the staged-version safety model: rotation stages `AWSPENDING`, promotes to `AWSCURRENT`, and demotes the old to `AWSPREVIOUS` only after `testSecret` succeeds. Confirm consumers fetch by `AWSCURRENT` (not a pinned version) so they pick up the new value, and that `testSecret` actually validates the new credential before promotion. 8. Check cross-account and multi-Region: if the secret/key is shared, confirm the key policy grants the external account and the consumer's IAM also allows it (KMS requires both), and that multi-Region keys or replica secrets are configured if consumers span Regions. Output as: (a) the key-policy findings with each over-broad statement quoted, (b) the principal-to-action access matrix with unjustified or missing grants flagged, (c) the rotation readiness verdict mapping each rotation step to its required permission, (d) the prioritized remediation list. Scope every KMS and Secrets Manager grant to the minimum action and resource needed — never grant `kms:*` or attach decrypt to a wildcard principal. Never enable or force rotation in production without confirming `testSecret` validates the credential and that consumers read `AWSCURRENT`; reproduce in a non-production secret and review before applying.
Why this prompt works
KMS is one of the few AWS services where IAM alone does not grant access — the key policy is the primary authority, and access requires both the key policy and the principal’s IAM to allow the action. Engineers who reason only in IAM terms produce an AccessDenied that looks like a workload failure when it is really a missing key-policy statement. This prompt anchors the review on the key policy as the source of truth, then builds a principal-to-action matrix, which is the only way to see whether each consumer has exactly the actions its encryption pattern requires and nothing more.
Rotation is where the subtle failures live, because it is a four-step state machine — createSecret, setSecret, testSecret, finishSecret — gated by staged version labels. Rotation promotes AWSPENDING to AWSCURRENT only after testSecret succeeds, and demotes the old value to AWSPREVIOUS. If the rotation Lambda’s role is missing a permission for one step, or if consumers pin a specific version instead of reading AWSCURRENT, rotation appears to succeed while the workload quietly breaks. Mapping each step to the permission it needs, and confirming the test step actually validates the new credential, catches this class of bug before it reaches production.
The envelope-encryption and grants checks close the remaining gaps. Envelope encryption depends on discarding the plaintext data key after use; storing or logging it defeats the entire model, so the prompt flags that explicitly. Grants — especially those AWS services create on your behalf — are a quiet source of lingering access that no one audits, so enumerating active grants and their retiring principals surfaces over-broad permissions that a key-policy review alone would miss. Together with least-privilege guardrails and a requirement to verify rotation in a non-production secret first, the prompt produces a review that is both thorough and safe to act on.