KMS Key Policy

What is a KMS key policy?

Every KMS key carries a key policy — a resource-based policy that is the primary authority over who can use and manage it. This is the KMS-specific twist that trips up even experienced IAM users: unlike most AWS resources where IAM policies alone grant access, a KMS key’s policy must explicitly delegate to IAM, or IAM permissions have no effect. The key policy is the root of trust; IAM policies and grants operate only within what it allows.

The two-tier access model

Access to a key comes from three layers that must align: the key policy (foundational — decides whether IAM is even consulted), IAM policies (per-principal permissions, effective only if the key policy delegates to the account), and grants (temporary, programmatic permissions AWS services create on your behalf — e.g., EBS asking to use a key for a volume). The standard safe pattern: a key policy that grants the account root kms:* (so IAM administration works normally) plus explicit statements for key administrators and key users. Deviating from this — trying to lock a key down by removing the account delegation — is where danger lives.

How keys get bricked

Because the key policy is the ultimate authority, a policy that grants access to no usable principal makes the key permanently unmanageable — you cannot fix it, because fixing it requires access the policy denies. AWS provides a support-driven recovery for exactly this self-lockout, but it’s a painful incident. The discipline: always retain a valid admin path (typically the account root or a break-glass admin role) in every key policy, and test policy changes on a non-production key.

What people get wrong

• Assuming IAM alone grants KMS access — without key-policy delegation, IAM permissions are inert.
• Locking out the account by over-restricting the policy in a security-hardening attempt.
• Ignoring grants when auditing: services hold key permissions via grants that don’t appear in the static policy.

Primary source: AWS KMS — key policies documentation

Key Policies vs. IAM Policies

A KMS key policy is distinct from, but interacts with, standard IAM policies: the key policy attached directly to a KMS key is the primary access control mechanism and must explicitly grant permission for any IAM policy-based access to take effect at all — a common source of confusion is assuming an IAM policy granting kms:Decrypt is sufficient, when the key’s own policy must also permit that principal’s access. This dual-layer requirement is a deliberate design choice giving key owners a final, centralized point of control over who can use a given key, independent of whatever broader IAM permissions might otherwise apply, which matters especially for keys protecting particularly sensitive data where an extra layer of explicit authorization is a meaningful safeguard against accidental overly broad access.