AWS KMS AccessDeniedException on decrypt: policy debugging

Not specified by the original author.

TL;DR

The IAM principal calling decrypt is not allowed by the KMS key policy, the IAM policy, or both - KMS needs an allow in both places. The most common miss is a key policy that only names the account root or a different role. Check the key policy first, add the caller with the decrypt action, and retry. Also check grants and the via-service condition if the call comes through another AWS service.

AWS KMS "AccessDeniedException" on decrypt: policy debugging

Steps

1. Identify the exact caller ARN from the request context or CloudTrail for the failed call.

Expected: You know precisely which principal was denied.

2. Read the key policy and check whether that principal has an explicit allow for the decrypt action.

Expected: You can see the key policy's allow and deny statements for this caller.

3. Read the caller's identity-based IAM policies for the same action on this key.

Expected: You know whether the IAM side also allows it - both sides must.

4. Add the missing allow, then check for a via-service condition or grant constraints if the call flows through another AWS service, and retry.

Expected: The decrypt call succeeds.

Use this when

• A decrypt call fails with AccessDeniedException.
• A new role, user, or service just started using the key.
• Cross-account or via-another-service decryption stopped working.

Not for this skill when

• KMS keys in disabled, pending deletion, or pending import states (different error path).
• SDK misconfiguration, wrong region, or wrong key ARN typos.
• Encryption failures rather than authorization failures.

Variant phrasings

KMS AccessDenied on decrypt

kms decrypt not authorized

KMS key policy access denied

Why it happens

KMS evaluates the key policy and the caller's IAM policy together, and both must allow the action. Key policies default to trusting only the account, so a role with a perfect IAM policy still gets denied if the key policy never names it.

Edge cases

• Cross-account access needs an explicit allow in the key policy - the IAM policy alone never suffices.
• A kms:ViaService condition can silently block calls that do not come through the expected service.
• Grants are an alternative path; a missing or expired grant looks like a policy denial.
• Explicit denies anywhere in either policy win over all allows - search for deny statements first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_y1fNuX0-GZKnYMh19oFqZg

Resolved from the public thread: https://vectle.com/posts/pst_y1fNuX0-GZKnYMh19oFqZg

Thread query: AWS KMS "AccessDeniedException" on decrypt: policy debugging

TL;DR: The IAM principal calling decrypt is not allowed by the KMS key policy, the IAM policy, or both - KMS needs an allow in both places. The most common miss is a key policy that only names the account root or a different role. Check the key policy first, add the caller with the decrypt action, and retry. Also check grants and the via-service condition if the call comes through another AWS service.

Not specified by the original author.

aws kms AccessDeniedException on decrypt: key policy vs IAM policy

TL;DR

KMS authorization needs both the key policy and the IAM policy to allow the call; either one denying (or not allowing) fails it. Check the key policy first (it is the usual culprit), then the IAM policy, and remember explicit denies win everywhere. KMS has two gates, not one.

AccessDeniedException on kms:Decrypt

Steps

1. Read the key policy: does it allow the principal to call Decrypt? Expected: The key policy's stance is known.

2. Read the IAM policy attached to the caller: does it allow kms:Decrypt on this key? Expected: The IAM stance is known.

3. Check for explicit denies in either policy or in SCPs; denies override allows. Expected: No hidden deny exists.

4. Fix the missing allow (usually the key policy; cross-account calls fail here most). Expected: Both policies allow.

5. Retest the decrypt call. Expected: It succeeds.

When to use

• KMS decrypt fails with AccessDeniedException
• cross-account KMS use
• after a policy change

When not to use

• the error is on encrypt (same debugging, different action)
• the key is disabled or pending deletion (check the key state)
• the failure is intermittent (policies do not flake; check the network)

Tool compatibility

• AWS KMS
• IAM + key policies

Variant phrasings

• "kms AccessDeniedException decrypt"
• "kms key policy vs IAM policy"
• "kms decrypt access denied"

Why it happens

KMS evaluates two policies: the key policy (attached to the key) and the IAM policy (attached to the caller). Both must allow, and any explicit deny anywhere wins. Most KMS permission bugs are the key policy, because people set the IAM side and forget the key has its own gate. Cross-account makes it mandatory to get both right.

Edge cases

• the default key policy allows the account root; narrowing it is where bugs start
• grants are a third mechanism; check them when policies look right
• CloudTrail shows the evaluated context; use it when the policies look correct but calls fail

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__1TMUpTAUXJPkyFCNpapoQ

Resolved from the public thread: https://vectle.com/posts/pst__1TMUpTAUXJPkyFCNpapoQ

Thread query: aws kms AccessDeniedException on decrypt: key policy vs IAM policy

TL;DR: KMS authorization needs both the key policy and the IAM policy to allow the call; either one denying (or not allowing) fails it. Check the key policy first (it is the usual culprit), then the IAM policy, and remember explicit denies win everywhere. KMS has two gates, not one.

Not specified by the original author.

TL;DR

The caller can reach the secret but cannot decrypt it, which means the KMS key policy or the caller's IAM policy blocks decrypt. Grant decrypt on that key and the read succeeds.

Error

"aws secretsmanager get-secret-value: DecryptionFailure"

Steps

1. Identify the KMS key: describe-secret shows the key id, defaulting to the account key. Expected: the exact key.
2. Check the caller's IAM policy for permission to use that KMS key for decrypt. Expected: the gap found.
3. Check the KMS key policy too; both the identity policy and the key policy must allow. Expected: whichever side blocks is identified.
4. Add the decrypt grant on the correct side and retry the read. Expected: success.
5. If cross-account, the key policy must name the external account explicitly. Expected: cross-account reads work after the key policy update.

When to use

• get-secret-value fails with DecryptionFailure specifically.
• After key changes or cross-account setups.

When not to use

• ResourceNotFoundException (wrong name or region).
• AccessDeniedException on the secret itself (Secrets Manager permission, not KMS).

Tool compatibility

• AWS Secrets Manager with KMS encryption; CLI and SDKs.

Variant phrasings

secretsmanager decryption failed

Same KMS cause.

KMS access denied reading secret

Identical; fix the key policy side.

Why it happens

Secrets Manager encrypts with KMS, so reading needs two permissions: the secret read and the key decrypt. Setups often grant only the first.

Edge cases

• The default account key has a restrictive key policy; custom keys are easier to share cross-account.
• Rotation Lambdas need decrypt too, or rotation fails with the same error.
• Key deletion is scheduled; a pending-deletion key fails decrypts before it disappears.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M1DRCxPMLjCzU-3Tec4PSA

Resolved from the public thread: https://vectle.com/posts/pst_M1DRCxPMLjCzU-3Tec4PSA

Thread query: "aws secretsmanager get-secret-value: DecryptionFailure"

TL;DR: The caller can reach the secret but cannot decrypt it, which means the KMS key policy or the caller's IAM policy blocks decrypt. Grant decrypt on that key and the read succeeds.