AWS Key Management Service (KMS) key policies are resource-based policies that control access to customer master keys (CMKs) in AWS KMS. They are fundamental to KMS security and determine who can use and manage your encryption keys.
Key policies are the primary way to control access to CMKs. Every…AWS Key Management Service (KMS) key policies are resource-based policies that control access to customer master keys (CMKs) in AWS KMS. They are fundamental to KMS security and determine who can use and manage your encryption keys.
Key policies are the primary way to control access to CMKs. Every CMK must have exactly one key policy, and this policy defines which principals (users, roles, accounts) can perform specific actions on the key. Unlike most AWS resources where IAM policies alone can grant access, KMS requires that the key policy explicitly allows access before IAM policies can be effective.
The default key policy created by AWS includes a root statement that gives the AWS account full access to the CMK through IAM policies. This enables you to use IAM policies in combination with the key policy. However, you can customize key policies to be more restrictive.
Key policy elements include:
- Principal: Specifies who gets access (AWS accounts, IAM users, roles, or services)
- Action: Defines allowed KMS operations like kms:Encrypt, kms:Decrypt, kms:GenerateDataKey
- Resource: Always set to '*' in key policies as it refers to the CMK itself
- Condition: Optional elements to add restrictions based on factors like source IP or encryption context
Best practices for KMS key policies include:
- Following least privilege principles
- Separating key administrators from key users
- Using conditions to restrict access based on encryption context
- Enabling key rotation for enhanced security
- Auditing key usage through CloudTrail
For cross-account access, both the key policy must allow the external account and the external account must have IAM policies permitting KMS actions. Understanding key policies is essential for the SysOps exam as they are critical for implementing encryption strategies and maintaining compliance requirements in AWS environments.
KMS Key Policies are the primary mechanism for controlling access to AWS KMS customer master keys (CMKs). They are fundamental to AWS security because they determine who can use and manage your encryption keys. Unlike most AWS resources where IAM policies alone control access, KMS requires a key policy to exist, making them essential for any encryption strategy in AWS.
What Are KMS Key Policies?
A KMS key policy is a resource-based policy attached to a KMS key that defines who can access the key and what actions they can perform. Every KMS key must have exactly one key policy. Key policies are JSON documents that specify:
• Principal - Who can access the key (AWS accounts, IAM users, roles, services) • Actions - What operations are allowed (encrypt, decrypt, create grants, etc.) • Resources - The KMS key itself (always "*" in key policies) • Conditions - Optional restrictions on when the policy applies
How KMS Key Policies Work
Default Key Policy: When you create a KMS key through the console, AWS creates a default key policy that: • Gives the AWS account (root user) full access to the key • Allows IAM policies to grant access to the key • Enables key administrators and key users as specified during creation
Key Policy + IAM Policy Model: For a principal to access a KMS key, they need: 1. Permission in the key policy (either explicitly or through the root account delegation) 2. Permission in their IAM policy
Key Policy Only Model: You can configure key policies to be the sole mechanism for access control by not including the statement that allows IAM policies to control access.
Key Policy Structure Example:
A typical key policy includes statements for: • Root account access (enables IAM policy integration) • Key administrators (can manage but not use the key) • Key users (can use the key for cryptographic operations) • Grants (allows delegation of key use to AWS services)
Important KMS Actions:
• kms:Encrypt - Encrypt data • kms:Decrypt - Decrypt data • kms:GenerateDataKey - Generate data keys for envelope encryption • kms:DescribeKey - View key metadata • kms:CreateGrant - Delegate permissions to AWS services • kms:PutKeyPolicy - Modify the key policy • kms:ScheduleKeyDeletion - Schedule key for deletion
Grants: Grants are an alternative to key policies for temporary or programmatic access delegation. They are commonly used by AWS services like EBS, RDS, and S3 to encrypt/decrypt data on your behalf.
Cross-Account Access: To allow another AWS account to use your KMS key: 1. Add the external account to the key policy 2. The external account must also have IAM policies allowing KMS actions
Exam Tips: Answering Questions on KMS Key Policies
• Remember the dual requirement: Access requires both key policy AND IAM policy permissions (unless key policy explicitly grants access)
• Root account statement: If the key policy includes the root account with full KMS access, IAM policies can then be used to delegate access to IAM users and roles
• Key administrators vs key users: Administrators manage the key (enable, disable, delete, modify policy) while users perform cryptographic operations (encrypt, decrypt)
• Cross-account scenarios: When questions mention cross-account access, both the key policy AND the IAM policy in the other account must allow the action
• Service integration: When AWS services need to use KMS keys, look for answers involving kms:CreateGrant and kms:ViaService conditions
• Troubleshooting access denied: Check both the key policy and IAM policy - missing permissions in either will result in access denied
• Default vs custom key policies: AWS managed keys have AWS-controlled policies; customer managed keys allow custom policies
• Key policy is required: Unlike IAM policies, you cannot delete a key policy - every KMS key must have one
• Condition keys: Know common conditions like kms:ViaService, kms:CallerAccount, and kms:EncryptionContext for restricting key usage