Mastering AWS KMS Grants: Benefits, Security Considerations, and a Practical Demo

Mastering AWS KMS Grants: Benefits, Security Considerations, and a Practical Demo

If you are securing cloud infrastructure for your company and use AWS KMS, understanding the use cases for KMS Grants is crucial for maintaining the accessibility and security of your KMS keys. This is particularly important for cloud security folks who examine AWS infrastructure and scrutinize the permissions assigned to various identities. Overlooking KMS Grants in your analysis creates a security gap, as a poorly managed AWS account can lead to exposed data resources and, in the worst cases, data leaks. Attackers could exploit little-known AWS concepts like Grants to create backdoors in your systems, allowing future access without the knowledge of data operators.

So what are AWS Grants? KMS keys are considered resources in AWS, similar to S3 buckets. The access model for KMS keys is governed by resource policy (KMS key policy) and the IAM policy attached to the identity accessing the resource. KMS Grants is an additional access mechanism provided by AWS as a temporary way of granting KMS permissions. When designing an access system, the KMS key policy or resource policy is used for assigning permissions to long-term identities. In contrast, Grants are intended for temporary permissions for specific KMS operations. Therefore, when assigning resource permissions to a KMS key, you have two options: updating the KMS key policy or creating Grants. To dig further in this, let’s see the KMS access model without Grants first.

If you prefer to watch a video instead, please take a look at the following video:

A refresher on how KMS access control works

Remember from our previous articles that when assigning KMS permissions, whether for intra-account or cross-account access, you need to grant the specific permission in both the IAM policy attached to the identity and the KMS key policy. This is an exceptional behavior for intra-account access compared to other resource policies, like those for S3, where either the IAM policy or resource policy alone is typically sufficient. To see this exception in action, watch the video demo below:

For example, in the diagram below (or think of it as a math equation 😀), both the IAM policy attached to Role XYZ and the KMS policy attached to Key 123 need to allow the kms:Decrypt permission for it to be granted.

So, how does this access model change when Grants are considered? 

KMS access control model with Grants

KMS Grants provide an alternative way for providing KMS permissions without updating the KMS key policy. If a Grant is created for the IAM role for the relevant cryptographic operation, and the IAM policy attached to the role allows that operation on the key, access is granted.

Updating the previous example, the total permissions provided by Key 123 now includes the sum of permissions from both the KMS key policy and KMS Grants. If these permissions are also allowed by the IAM policy attached to Role XYZ, the operations will be permitted.

KMS Grants benefit for temporary access to the KMS Key

You might wonder why we need Grants if we already have a way of assigning KMS permissions using Key policy. KMS key policies represent the resource permissions attached to the KMS key and are designed for long-term permissions. However, in cloud infrastructure, there are often situations requiring temporary permissions to the KMS key. In these scenarios, KMS Grants are extremely useful. Examples of situations needing short-term access to a KMS key include:

• Data Migration project – When an organization needs to migrate data from one storage solution to another, they might require temporary access to decrypt data using a specific KMS key. A KMS Grant can be created to allow the migration tool to use the key for decryption purposes during the migration period. 
• Automated Maintenance processes – During automated maintenance processes e.g. backup, a system might need temporary access to the KMS keys in order to encrypt or decrypt data. KMS Grants can be used to provide access to the maintenance service for the time required to complete the maintenance operation.

KMS Grants benefit for fine-grained access control

Another security benefit of using KMS Grants is the fine-grained access control they offer. Unlike KMS policies, which can grant full access (“*”) to any identity, Grants can only be created for specific operations. From a security standpoint, the blast radius of a poorly configured KMS key policy could expose the administrative permissions of the KMS key. However, for a KMS Grant, the exposure is limited to the specific operations the Grant was created for.

Below is the list of operations for which Grants can be created. Please note that this information is based on AWS documentation at the time of writing, and permissions may have changed since.

Cryptographic operations

• Decrypt
• Encrypt
• GenerateDataKey, GenerateDataKeyPair, GenerateDataKeyPairWithoutPlaintext, GenerateDataKeyWithoutPlaintext
• GenerateMac
• ReEncryptFrom
• ReEncryptTo
• Sign
• Verify
• VerifyMac

Other operations

• CreateGrant
• DescribeKey
• GetPublicKey
• RetireGrant

These are great benefits, but are there any Security risks with using KMS Grants?

So remember when I mentioned that KMS Grants are intended for “temporary access”? That’s only partly true. While the purpose of Grants is to provide temporary access, they do not automatically expire. This poses a significant security risk because if cloud security teams are not actively monitoring and deleting unused Grants, it can lead to vulnerabilities for encrypted resources. Attackers could exploit this by creating backdoor access to encrypted resources in AWS accounts, potentially keeping their actions unnoticed.

A practical demo of KMS Grants using the example of cross-account S3 access

If you are looking to enable cross-account S3 access using KMS Grants or just looking for an easy way to understand how KMS Grants work, here is a demo on AWS that you can follow. I have created a youtube video on this demo, so you can take a look at that if you prefer:

Let’s start with a quick blueprint of how this demo would work (refer to the diagram below). In this demo, we have 2 AWS accounts – Data account (hosting the S3 bucket) and the Accessor account (containing the IAM Role). 

• Initially, we will establish cross-account access to the bucket object from the IAM Role by adjusting both the S3 bucket policy and the IAM Role policy. At this stage, since the bucket lacks KMS encryption, access will succeed.

• Next, we will enable KMS encryption on the S3 bucket using a newly created KMS key with the default KMS policy. At this juncture, due to the default AWS-provided policy on the KMS key, the IAM role cannot decrypt the KMS key therefore it cannot access our bucket. 

• We will then explore the two solutions for granting KMS key access: first, by modifying the KMS key policy, and secondly, by utilizing KMS Grants.

Let’s dive into the technical steps of the demo: 

♦ 1 ♦ Within the Data AWS account, create an S3 bucket ABC without KMS encryption. Upload a test object file and modify the S3 bucket policy to permit downloading of the test object by IAM Role XYZ in the Accessor AWS Account.

♦ 2 ♦ In the Accessor AWS account, create an IAM Role XYZ with an inline AWS Policy that permits downloading the S3 bucket ABC test object.

♦ 3 ♦ Assume Role XYZ and attempt to download the S3 bucket ABC object. This should be successful, indicating that cross-account AWS access has been successfully enabled.

♦ 4 ♦ In the Data account, generate a KMS key with a default KMS policy and update the S3 ABC settings to activate encryption using the newly created KMS key. Repeat STEP 3. This should result in an ERROR because Role XYZ lacks permission to decrypt the KMS key.

♦ 5 ♦ (Solution using KMS Key policy update) – Adjust the KMS Key policy to grant decrypt permissions to Role XYZ. Repeat STEP 3; this action should now succeed.

♦ 6 ♦ (Solution using KMS Grants) – Reverse the KMS key policy change from STEP 5. Next, within the Data account, establish a KMS Grant for the KMS key, allowing the DECRYPT operation for Role XYZ. Repeat STEP 3; this action should now succeed.

Thanks for reading!

Follow us on:

• YouTube
• Twitter