Build KMS key policies with principals, conditions, and common grant patterns.
Last verified: April 2026
Note: Key rotation is a key-level setting, not part of the key policy itself
Output will appear here...The builder constructs a KMS key policy JSON document using a template system that combines separate statement blocks for the root account enablement, key administrators, key users, and grants. Each statement block uses the minimum set of KMS actions required for its role. For cross-account access, it adds the appropriate principal ARN with optional conditions like kms:ViaService to restrict which AWS service can use the key.
AWS KMS key policies are the primary access control mechanism for encryption keys — unlike most AWS resources, KMS keys do not inherit permissions from IAM policies unless the key policy explicitly allows it. This makes key policies uniquely critical: a misconfigured key policy can either lock everyone (including root) out of the key permanently or grant unintended decryption access across accounts. The builder provides guided forms for key administrators, key users, grant patterns, and cross-account access with appropriate conditions, following AWS's recommended key policy structure.
A data engineering team needs to share an encrypted S3 bucket with an analytics team in a different AWS account. They've tried adding cross-account S3 bucket policies but keep getting 'Access Denied' when the analytics team tries to download objects. The issue: the KMS key policy only allows the source account to decrypt. You use the builder to add a cross-account key user statement with the analytics account as principal and a kms:ViaService condition restricting usage to S3 only. The analytics team can now read objects, but can't use the key for anything else.
KMS key policies are the ONLY resource-based policies in AWS where the root principal statement is functionally required. Without 'Allow root account kms:*', IAM policies in your account cannot grant key access at all — even for administrators. Removing this statement can permanently lock you out of the key with no recovery option.
When sharing encrypted resources cross-account (S3 buckets, EBS snapshots, RDS backups), you need BOTH a key policy granting the external account access AND an IAM policy in the external account granting the user permission to use the key. Missing either side silently fails with 'Access Denied' on decrypt.
Use separate key policies for key administrators and key users. Key administrators should have kms:Create*, kms:Describe*, kms:Enable*, kms:List*, kms:Put*, kms:Update*, kms:Revoke*, kms:Disable*, kms:Get*, kms:Delete*, kms:ScheduleKeyDeletion, and kms:CancelKeyDeletion — but NOT kms:Encrypt, kms:Decrypt, or kms:GenerateDataKey. This separation of duties prevents admins from accessing encrypted data.
The default key policy grants kms:* to the root principal (arn:aws:iam::ACCOUNT:root) not to give the root user direct access, but to enable IAM policies in the account to control key access. Without this statement, no IAM policy — including those attached to administrators — can grant KMS permissions, and only the key policy itself controls access. Removing this statement risks permanently locking everyone out of the key if the key policy does not include other explicit grants.
Key policies are JSON documents attached directly to the key, like resource-based policies on S3 buckets. Grants are programmatic, temporary access tokens that allow a principal to use a key for specific operations. AWS services use grants extensively — when you create an encrypted EBS volume, EBS creates a grant on the KMS key so it can decrypt the volume key. Grants can be revoked instantly and do not require modifying the key policy, making them ideal for transient access.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.