KMS Key Policy
The resource policy that is the root authority over a KMS key — powerful enough to lock out even the account root, which is exactly how people brick keys.
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
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.