Understanding Key Policies in AWS KMS

all aws aws kms aws security Jan 29, 2024

Introduction

Understanding how to control access to our KMS keys is essential for maintaining data security and compliance. Here, we'll demystify the key policies in AWS KMS, making it simple to grasp their importance and how to use them effectively.

The Basics of KMS Key Policies

A KMS key policy is a JSON document that clearly specifies who can access the key and under what conditions. The policy structure allows for granular control, including specifying actions (like "kms:Encrypt" or "kms:Decrypt"), effect (allow or deny), and resources. It enables precise management of permissions, ensuring that only authorized users and services can perform cryptographic operations or manage the key.

At the core, controlling access to KMS keys is similar to managing access to S3 bucket policies. However, a key distinction is that we cannot access KMS keys without defining key policies; however, we can access the S3 bucket without creating an S3 bucket policy as the access permissions can also be set through other means such as IAM, ACLs, public bucket settings, etc.

Default KMS Key Policy

When we create a new AWS KMS key and don't specify a key policy, AWS KMS automatically attaches a default key policy to the key. This default policy is designed to give full access to the key to the account's root user.  We can further use IAM policies to allow other IAM users and services access to the key. In a way, the default KMS policy delegate access control to IAM.

Custom KMS Key Policy

Custom KMS Key Policies allow us to define precisely who can access and administer our KMS keys. This is where we can specify which users or roles can manage the key's permissions (key administrators) and who can use the key (key users).

Custom policies are particularly useful for scenarios requiring cross-account access, enabling us to securely share our cryptographic keys with users from another AWS account.

Types of KMS Key Policies

Understanding the different types of keys available in AWS KMS is essential for managing our key policies:

  • AWS Owned Keys: These are keys owned and managed by AWS for use in multiple AWS accounts. We cannot view or change the key policy of these keys.

  • AWS Managed Keys (e.g., aws/ebs): AWS manages these keys, but they are designated for our account's use. We can view the key policy but cannot change it.

  • AWS Customer Managed Keys: These are keys that we manage and have full control over. We can view and edit the key policy, offering the most flexibility for managing access.

Customizing Our KMS Key Policy

For Admins

For our AWS Customer Managed Keys, we can define administrators who have permission to manage the key itself. It's important to note that being an administrator does not grant the ability to perform cryptographic operations with the key (like encrypting or decrypting data). Instead, administrators can manage the key's policy and permissions.

For Users

We can also specify which IAM users or roles can use the KMS key directly for cryptographic operations. If the KMS key and the IAM principal are in the same account, we don't need to attach IAM policies to those users or roles for them to use the key; the key policy itself is enough to grant this permission. However,  IAM policies can still be useful to restrict a user's or role's actions to a subset of what the key policy allows or enforce conditions for access (like MFA authentication).

Conclusion

Managing key policies in AWS KMS is foundational to securing our cloud environment. By understanding and utilizing the default and custom key policies, we can ensure that our keys are accessible only to the right users and services. Whether we're using AWS-managed keys for common AWS services or managing our own keys for granular control, the key policy is our tool for safeguarding access to our cryptographic keys.

Stay connected with news and updates!

Join our mailing list to receive the latest news and updates from our team.
Don't worry, your information will not be shared.

We hate SPAM. We will never sell your information, for any reason.