AWS KMS Key Policy Builder Tool - Visual Builder and Linter for AWS KMS Key Policies

First Published:
Last Updated:

Build, lint, and harden AWS KMS key policies in your browser. Compose role-based statements (account / root delegation, key administrators, key users, grant delegation, and kms:ViaService service scoping), generate formatted JSON or CloudFormation YAML, and paste an existing key policy to check for the classic KMS pitfalls — most importantly the lockout that makes a key unmanageable.

All processing is performed entirely in your browser using client-side JavaScript. No data is transmitted to any server. Your key policy never leaves your device.

  • This tool is provided "AS IS" without any warranties of any kind.
  • The author accepts no responsibility for misconfigured key policies that cause data loss, lockout, privilege escalation, or service disruption.
  • The built-in linter is heuristic and advisory only; it is not a substitute for AWS IAM Access Analyzer or a security review.
  • Never remove administrative access from a key without a tested recovery path. A locked-out key may require AWS Support to recover.
  • By using this tool, you accept full responsibility for any outcomes.

This tool uses client-side JavaScript for all processing. No data is transmitted to servers, no files are uploaded online, all processing happens locally in your browser. Once loaded, this tool continues to work even without an internet connection. For more details, please refer to our Web Tools Disclaimer.

1. Key Configuration

2. Presets

Click a preset to replace the current statements with a starting point. Presets use AWS documentation dummy values (account 111122223333, external account 444455556666, roles ExampleAdminRole / ExampleUserRole) — replace them with your own.

3. Statements

4. Generated Output

// Add a statement (or load a preset) to see the generated key policy.

5. Live Checks

Findings update as you edit. Severities: Error (structural / spec violation), Warning (risk), Info (recommendation). A clean result is not a security guarantee.

Paste or Drop a Key Policy

Load an example to see how the checks behave:

Drag and drop a .json key policy file here, or press Enter / Space to browse.

Findings

Features

  • Role-based statement builder: Each statement starts from a role template — Account / root delegation, Key administrators, Key users (cryptographic), Grant delegation for AWS services, Service-scoped use (kms:ViaService), or a fully custom statement — that pre-fills the matching AWS KMS actions.
  • Key-type aware actions: Choosing Symmetric, HMAC, or one of the asymmetric key usages (encrypt/decrypt, sign/verify, key agreement) changes the cryptographic actions offered to key users to match the operations that key type supports.
  • Seven presets: Console Default (full), Programmatic Minimal, Administrators / Users Separation, Service Integration, Cross-Account Key User, Encryption Context Restriction, and a deliberately Dangerous Lockout Example for testing the linter.
  • Three output formats: Pretty JSON for the AWS console / PutKeyPolicy, Minified JSON for IaC variables, and CloudFormation YAML for the KeyPolicy property of AWS::KMS::Key.
  • Lockout-aware linter: The headline KMS pitfall — a key policy that no longer lets anyone change it, or that omits the account-root statement that enables IAM delegation — is detected and explained.
  • 12 checks across three severities: structural errors (missing Principal / Action / Resource, Resource not "*"), risk warnings ("*" principal without a condition, kms:* to non-account principals, direct kms:CreateGrant, typo / non-KMS actions, ForAllValues with kms:EncryptionContext), and informational notes.
  • Bidirectional: Paste an existing policy or drop a .json file into the Linter, or lint the policy you just built with one click.
  • 100% client-side: No fetch, no XMLHttpRequest, no WebSocket, no AWS calls. The page works offline once loaded.

How to Use

  1. On the Builder tab, pick the Key type so the cryptographic actions match your key, then optionally set a Policy Id.
  2. Click a Preset for a starting point, or + Add Statement to build from scratch.
  3. For each statement, choose a Role template (which pre-fills actions), set the Effect, enter the Principal ARNs (one per line), tick the Actions you need, and add Conditions such as kms:ViaService or kms:GrantIsForAWSResource. The Resource is fixed to "*" automatically.
  4. Watch Live Checks for lockout and over-permission findings as you edit, then copy or download the Generated Output in your preferred format.
  5. To audit an existing policy, open the Linter tab, paste the JSON (or drop a .json file), and click Lint Policy. Use the example buttons to see how each finding looks.
  6. Replace every placeholder account ID, role name, and Region before using the policy in AWS.

About This Tool

An AWS KMS key policy is the resource-based policy attached to a KMS key. Unlike most AWS resource policies, a key policy does not automatically grant the owning account any access: the account and its IAM policies can control the key only when the key policy explicitly says so — which is why the default policy includes the "Enable IAM User Permissions" statement granting kms:* to arn:aws:iam::<account-id>:root. Omitting that statement, or scoping the only administrative access to principals that can later be deleted, is how keys become unmanageable and require AWS Support to recover.

This tool helps you compose key policies from the same building blocks AWS uses in its default policy — an account-delegation statement, a key administrators statement, key users statements for cryptographic operations, and a grant-delegation statement gated by kms:GrantIsForAWSResource — and then lints the result for the most common mistakes. The action groups, condition keys, default-policy structure, and lockout guidance were verified against the AWS KMS Developer Guide: Creating a key policy, Default key policy, and AWS KMS condition keys as of 2026-06-23. AWS may add actions and condition keys over time; always re-check against the current documentation.

Important Notes

  • This is guidance, not an audit: This builder generates and lints AWS KMS key policies following official documentation as of 2026-06-23. Lockout and over-permission warnings are best-effort guidance, not a security audit. Effective key access also depends on IAM policies and grants — review carefully and avoid removing administrative access from a key.
  • A clean lint does not mean "secure": Passing the built-in checks only means none of this tool's heuristics fired. It does not prove the policy is least-privilege or safe.
  • Key policy vs IAM policy: A key policy lives on the KMS key and only governs kms: actions on that key (Resource is always "*"). To grant a principal access through IAM, the key policy must first enable IAM delegation (the account-root statement). For identity-based policies, use the IAM Policy Least Privilege Analyzer or IAM Policy Simulator (Offline) instead.
  • Avoid lockout: Always keep an Allow statement granting kms:* (or at least kms:PutKeyPolicy) to the account principal arn:aws:iam::<account-id>:root, which cannot be deleted. AWS runs a policy lockout safety check on PutKeyPolicy for exactly this reason.
  • Grants and kms:ViaService: Granting kms:CreateGrant directly is powerful. For AWS service integration, gate it with kms:GrantIsForAWSResource; to limit a key to specific services, use kms:ViaService with the <service>.<region>.amazonaws.com name.
  • 32 KB limit: A key policy document can be up to 32 KB (32,768 bytes). The Builder shows the current size and warns at 80% of the limit.
  • Placeholder values: Account IDs 111122223333 / 444455556666 and role names ExampleAdminRole / ExampleUserRole are AWS documentation dummy values. Replace them with your own.
  • Validate before use: Confirm the policy with IAM Access Analyzer policy validation and review it against the official AWS KMS key policy documentation before applying it to a production key. This tool does not connect to AWS.

FAQ

What is a key policy, and how is it different from an IAM policy?
A key policy is the resource-based policy on a KMS key; it lists which principals may perform kms: actions on that specific key (Resource is always "*"). An IAM policy is identity-based and attached to a user or role. For an IAM policy to grant access to a key, the key policy must first delegate to IAM via the account-root statement. Both are evaluated together.

How do I avoid locking myself out of a key?
Keep an Allow statement that grants kms:* (or at least kms:PutKeyPolicy) to arn:aws:iam::<account-id>:root. The account principal represents the account and its administrators, including the root user, which cannot be deleted. Without it, IAM Allow policies are ineffective and the key can become unmanageable. The Linter flags both situations.

What is the difference between key administrators and key users?
Key administrators can manage the key (create aliases and grants, change the policy, enable/disable, schedule deletion) but cannot use it in cryptographic operations by default. Key users can use the key directly (encrypt, decrypt, generate data keys, sign, and so on). Separating these roles is a common least-privilege pattern available as a preset.

What does kms:ViaService do?
It limits use of the key to requests that come through specific AWS services, named as <service>.<region>.amazonaws.com (for example s3.us-west-2.amazonaws.com). It is how AWS managed keys restrict themselves to a single service, and you can use it to scope a customer managed key the same way.

What is a grant, and why does kms:GrantIsForAWSResource matter?
A grant is a separate, more granular way to delegate temporary key usage, often created by AWS services on your behalf (for example, EBS attaching an encrypted volume). Adding "Condition": { "Bool": { "kms:GrantIsForAWSResource": true } } to a kms:CreateGrant statement allows integrated services to create grants for the principal, without letting the principal call CreateGrant directly — which would otherwise be a broad delegation of power.

Related Tools

Related Articles


References:
Tech Blog with curated related content
Web Tools Collection

Written by Hidekazu Konishi