A role in the same AWS account has an IAM policy allowing kms:Decrypt on a customer managed KMS key, but its calls still fail with AccessDenied. Why does KMS behave differently from most AWS resource policies here, and how do you fix it?

## The rule that makes KMS different For most AWS resources, a resource-based policy is optional and additive: an S3 bucket with no bucket policy is still reachable by a principal in the same account whose IAM policy allows `s3:GetObject`. KMS inverts that default. **Every KMS key has a key policy, you cannot delete it, and it is the primary authority for the key.** A principal gets access only if the key policy allows it — directly, or by explicitly handing authority to IAM. That is what the default key policy does. When you create a customer managed key without specifying a policy, KMS attaches one containing a single statement: ```json { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "kms:*", "Resource": "*" } ``` The `root` principal here does not mean the root user. It means *the account*, and the statement's real function is to say "IAM policies in this account may grant access to this key." With it in place, KMS behaves the way engineers expect and an IAM allow is enough. Take it out — which happens the moment someone hardens the key by replacing the policy with an explicit list of principals — and IAM policies referencing that key stop having any effect, silently, for every principal not named in the new document. ## Diagnosing it The symptom is an `AccessDeniedException` on `kms:Decrypt` or `kms:GenerateDataKey` from a role whose IAM policy plainly allows the action. The message text is the tell: KMS distinguishes a denial where no resource-based policy allows the action from an ordinary identity-policy denial. The confirming step is to read the key policy itself (`aws kms get-key-policy --key-id <id> --policy-name default`) and look for the account-root delegation statement. Its absence, or a `Condition` on it that the caller does not satisfy, is the answer nine times out of ten. Two related traps produce the same symptom. First, a `Condition` such as `kms:ViaService` on the allow statement restricts use to requests that a named AWS service makes on your behalf — a direct SDK call from the role then fails even though the same role succeeds through that service. Second, the caller may be a *session* whose permissions were narrowed by a session policy or a permissions boundary, in which case the key policy is fine and the ceiling is elsewhere. ## Fixing it Two shapes are legitimate: - **Restore the delegation** and keep per-principal detail in IAM. This scales — you manage access in one place — but it means anyone with IAM-editing power in the account can grant themselves the key. - **Name principals in the key policy.** Stricter, and required for cross-account access, where both sides must allow: the key policy must name the external principal *and* that principal's own IAM policy must allow the action. A scoped statement looks like: ```json { "Sid": "AllowAppRuntimeUse", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-runtime" }, "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"], "Resource": "*" } ``` `Resource` is `*` because a key policy is attached to exactly one key — it can mean nothing else. ## Grants, and the lockout guard Grants are KMS's third authorization mechanism, and the one people forget in this discussion. A grant is a separate, temporary allowance created with `CreateGrant`, naming a `GranteePrincipal`, a list of `Operations`, an optional `RetiringPrincipal`, and optional constraints. AWS services use grants heavily to obtain scoped, revocable use of your key on your behalf. They are additive to the key policy, they can be retired or revoked individually, and they avoid rewriting a shared policy document for a short-lived need — but the key policy must still permit `kms:CreateGrant` for whoever creates one. Because the key policy is the root of authority, it is possible to write one that leaves nobody able to manage the key. KMS runs a lockout safety check on `CreateKey` and `PutKeyPolicy` that rejects such a policy, which you can override with `BypassPolicyLockoutSafetyCheck`. Overriding it on a production key is how a key becomes permanently unmanageable — there is no support path back.