Key Policies, Grants, and Conditions

Creating a key is half the job; controlling who may use it is the other half. KMS uses several access mechanisms layered together.

The most important is the key policy, the resource-based policy attached directly to the key.

Every KMS key has a key policy that is the primary authority over access.

• Unlike most services, a KMS key must have a key policy.
• If the key policy does not grant access, IAM policies alone cannot.

This makes the key policy the gatekeeper.

Access to a KMS key requires the key policy to enable IAM, then IAM and key policy combine.

The default key policy includes a statement giving the account's IAM principals access subject to their IAM policies. Without that statement, only principals named directly in the key policy can use the key.

A grant is a flexible, temporary way to delegate use of a key.

• It allows specific operations to a principal, often programmatically.
• AWS services use grants to access keys on your behalf.

Grants can be retired or revoked when no longer needed, ideal for short-lived delegation.

Choose by lifetime and granularity:

• Use the key policy and IAM for long-standing, broad access.
• Use grants for fine-grained, temporary permissions, often created dynamically by services or apps.

Grants avoid editing the key policy for short-term needs.

KMS supports powerful condition keys in policies, such as kms:ViaService.

ViaService restricts key use to requests coming through a specific AWS service (like only via S3), so a principal can decrypt only when S3 makes the call, not directly.

Encryption context is a set of key-value pairs passed with encrypt/decrypt that is cryptographically bound to the operation.

• The same context must be supplied to decrypt.
• It appears in CloudTrail for auditing.

Policies can require a specific context with the kms:EncryptionContext condition.

To let another account use a key, the key policy must allow that external account, and the external principal needs IAM permission too.

This is the same two-sided pattern as cross-account roles: the resource policy (here, the key policy) and the caller's IAM policy must both permit the action.

Apply least privilege to keys:

• Separate key administrators (manage the key) from key users (encrypt/decrypt).
• Avoid kms:* for users.
• Use ViaService and encryption context to tighten scope.

This limits blast radius if a principal is compromised.

A classic mistake is editing a key policy and removing the statement that enables IAM.

Without it, even account administrators lose access, and because the key policy is the gatekeeper, you can lock yourself out of the key entirely. Always keep an account-level administrative principal in the key policy to avoid an unrecoverable key.

Combine CloudTrail (every KMS call with context) and IAM Access Analyzer (key policies granting external access) to audit who can and does use each key.

Regular review catches over-broad key policies before they become a risk.

Reason about KMS access.

You learned how KMS access is controlled.

• The key policy is the primary gatekeeper and must enable IAM to use it.
• Grants give temporary, fine-grained delegation.
• Conditions like ViaService and encryption context tighten scope.