AWS KMS Key Policies | Deep Dive

Here’s twtech deep dive into AWS KMS Key Policies.

Focus:

•         The Concept: KMS Key Policy,
•         Relationship Between Key Policies, IAM Policies, and Grants,
•         Structure of a Key Policy,
•         Common Policy Sections,
•         Key Policy Evaluation Logic,
•         Default vs Custom Key Policies,
•         Data Re-encryption and KMS APIs,
•        Best Practices,
•         CloudTrail and Monitoring,
•         Useful Links from AWS Documentaion.

 1. The Concept: KMS Key Policy

•        A KMS key policy is the primary access control document for a KMS Customer Managed Key (CMK).
•        KMS key policy defines who can use or manage the key and how it can be used.
•        Every KMS key (CMK) has exactly one key policy, stored and enforced within KMS.
•        Unlike IAM policies, which attach to users or roles, key policies attach directly to the KMS key.

 2. Relationship Between Key Policies, IAM Policies, and Grants

Access Mechanism	Description	Scope
Key Policy	Core access control document attached to the KMS key. Defines who can administer or use the key.	Required for all KMS CMKs
IAM Policy	Defines what KMS actions a user or role can perform, subject to the key policy.	Optional but recommended
Grant	A temporary, fine-grained permission on a KMS key (e.g., for AWS services).	Runtime / delegated access

NB:

To perform any action with a key, both the IAM policy and the key policy must allow it — unless the key policy gives full access to AWS account root.

 3. Structure of a Key Policy

A key policy is written in JSON, similar to IAM policies.

Example: Minimal Key Policy

# json

{

  "Version": "2012-10-17",

  "Id": "key-default-1",

  "Statement": [

    {

      "Sid": "twtech-Allow-Administration-of-the-key",

      "Effect": "Allow",

      "Principal": { "AWS": "arn:aws:iam::acccountID:root" },

      "Action": "kms:*",

      "Resource": "*"

    }

  ]

}

NB:

The above policy gives full control of the key to the AWS account root.

 4. Common Policy Sections

a. Administrative Permissions

Grants permission to manage key settings (enable/disable, rotate keys, etc.)

# json 

{

  "Sid": "Allow key administrators",

  "Effect": "Allow",

  "Principal": { "AWS": "arn:aws:iam::accountID:role/twtechKMSAdminRole" },

  "Action": [

    "kms:Create*",

    "kms:Describe*",

    "kms:Enable*",

    "kms:Disable*",

    "kms:Put*",

    "kms:Update*",

    "kms:Revoke*",

    "kms:ScheduleKeyDeletion",

    "kms:CancelKeyDeletion"

  ],

  "Resource": "*"

}

b. Usage Permissions

Allows encryption, decryption, and re-encryption actions.

# json

{

  "Sid": "Allow use of the key for encryption",

  "Effect": "Allow",

  "Principal": { "AWS": "arn:aws:iam::AccountID:role/twtechAppServerRole" },

  "Action": [

    "kms:Encrypt",

    "kms:Decrypt",

    "kms:ReEncrypt*",

    "kms:GenerateDataKey*"

  ],

  "Resource": "*"

}

 5. Key Policy Evaluation Logic

A request to KMS passes three checks:

1.      Key Policy — Does the policy attached to the key allow the action?
2.      IAM Policy — Does the caller’s IAM policy allow the KMS action?
3.      Grant — Are there temporary permissions allowing the action?

If any of these deny the request, access is blocked.

6. Default vs Custom Key Policies

Type	Description		Recommended?
Default policy		Automatically created when you create a CMK through the console. Grants full access to account root and integrates IAM policies.	✅ Yes (good for most users)
Custom policy		Fully defined by the user. Useful for cross-account access or service integrations.	⚠️ Advanced users only

 7. Data Re-encryption and KMS APIs

When re-encrypting EBS or S3 data:

1.    EBS or S3 calls kms:ReEncrypt* APIs.
2.      KMS decrypts data with the old CMK and re-encrypts with the new CMK.
3.      CloudTrail logs ReEncrypt events for auditing.
4.      IAM and Key Policy permissions determine if the re-encryption request is allowed.

 8. Best Practices

• Enable key rotation for long-lived CMKs.
• Use grants for temporary service permissions (e.g., EC2, RDS).
• Keep root principal in policy only to allow account-wide IAM control.
• Limit administrative permissions — separate admin and usage roles.
• Monitor with CloudTrail – look for kms:Decrypt, kms:GenerateDataKey, and kms:ScheduleKeyDeletion events.
• Use AWS Config to detect overly permissive key policies.

9. CloudTrail and Monitoring

Every KMS API call (Encrypt, Decrypt, GenerateDataKey, etc.) is logged to AWS CloudTrail, including:

•         Principal ARN
•         Key ID
•         API action
•         Encryption context
•         Region and timestamp

These logs are critical for auditing key usage and detecting potential misuse.

10. Useful Links from AWS Documentaion

•         AWS KMS Developer Guide – Key Policies ( https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html )
•         AWS KMS API Reference ( https://docs.aws.amazon.com/kms/latest/APIReference/Welcome.html )
•         CloudTrail Integration with KMS ( https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html )