AWS KMS Permission Issue: User Not Authorized to Perform kms:CreateGrant

Understanding the CreateGrant Operation

In AWS Key Management Service (KMS), encryption operations often require a cryptographic grant. A grant allows a service or user to use a CMK without exposing the key material itself. When you see the kms:CreateGrant error, it means the requesting entity has permission to use the key (e.g., kms:Encrypt) but does not have permission to establish the grant mechanism required by modern AWS services. This is distinct from simply having access to the key; it is a separate authorization step.

If you are managing infrastructure via code, such as Terraform or CloudFormation, this error frequently appears during the initial provisioning phase. For example, when creating an encrypted EBS volume, the EC2 service needs to create a grant on the KMS key. If the EC2 service role or the user triggering the creation doesn't have kms:CreateGrant, the process fails immediately. It is important to note that grants can be created with constraints, limiting how the grantee can use the key, which adds a layer of security beyond simple key access.

Auditing Current Permissions

Before modifying policies, you should verify exactly which identity is failing and what permissions they currently hold. Use the AWS IAM Policy Simulator to test the scenario. Enter the ARN of the user or role, select the kms:CreateGrant action, and specify the resource ARN of the KMS key. The simulator will tell you if the request is allowed, denied, or if there is an explicit deny from a service control policy (SCP).

Additionally, check the KMS key policy. By default, the account root user has full access, but other principals might be restricted. If you are using a shared environment, ensure that the KMS key policy explicitly lists the accounts or users that need to create grants. You can view the key policy in the AWS Management Console under the "Key users" tab or by using the aws kms describe-key command. Look for statements that include kms:CreateGrant in the Action array.

Updating IAM User Policies

If the issue lies with a specific IAM user or role, you need to attach a policy that grants the necessary permissions. You can do this by attaching an inline policy or a managed policy to the identity. Below is an example of an IAM policy document that allows kms:CreateGrant for a specific key.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:CreateGrant",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:region:account-id:key/key-id"
    }
  ]
}

Replace region, account-id, and key-id with your actual values. Note that including kms:DescribeKey is often helpful because many applications call this API first to verify the key exists before attempting to create a grant. Without it, you might encounter a secondary error regarding key description visibility. Always apply the principle of least privilege; restrict the Resource field to only the keys that the user absolutely needs to manage.

Updating the KMS Key Policy

Sometimes, the IAM policy is correct, but the KMS key policy blocks the action. This happens if the key policy is restrictive and does not list the requesting principal. To fix this, go to the KMS console, select the key, and choose "Edit key policy." Add a statement similar to the one below:

{
  "Sid": "AllowCreateGrantForService",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::account-id:role/role-name"
  },
  "Action": [
    "kms:CreateGrant",
    "kms:Decrypt",
    "kms:Encrypt"
  ],
  "Resource": "*"
}

This approach is particularly useful when granting permissions to AWS services themselves, such as allowing an S3 bucket to encrypt objects with a specific KMS key. The service role acting on behalf of the service must be listed in the key policy. If you are unsure about the exact role ARN, check the service documentation for the specific AWS service you are integrating with.

Common Troubleshooting Steps

• Check for Explicit Denies: Review your Organization SCPs and IAM Permission Boundaries. An explicit deny at any level overrides allow statements in user policies.
• Verify Key State: Ensure the KMS key is enabled. Disabled keys cannot be used for any operations, including grant creation. Check the key state in the KMS console.
• Review Recent Changes: Did you recently rotate the key alias or change the key policy? Sometimes, caching issues in the AWS SDK can cause temporary failures. Wait a few minutes and retry.
• Check Multi-Region Keys: If you are using a multi-region primary key, ensure you are calling CreateGrant on the correct region. Grants are regional resources.

Resolving permission issues in AWS requires careful attention to both identity-based and resource-based policies. By ensuring that both the IAM principal and the KMS key policy explicitly allow kms:CreateGrant, you can prevent these errors and maintain secure, encrypted workflows across your infrastructure.

Frequently Asked Questions

Why do I get an error even though I have kms:Encrypt permission?

Having kms:Encrypt allows you to use the key, but it does not authorize you to create the cryptographic grant required by many AWS services. Modern AWS services automatically attempt to create a grant when they use a customer-managed key. You must explicitly add kms:CreateGrant to your policy to satisfy this requirement.

Can I use a wildcard (*) in the Resource field for kms:CreateGrant?

While technically possible, using a wildcard is discouraged due to security risks. It allows the identity to create grants on any KMS key in the account. Instead, specify the exact ARN of the key you need to manage. This follows the principle of least privilege and prevents accidental or malicious misuse of other keys.

Does kms:CreateGrant require kms:Decrypt permission?

No, kms:CreateGrant does not strictly require kms:Decrypt. However, most practical scenarios involve using the key for encryption and decryption. If your application needs to decrypt data, you must add kms:Decrypt separately. The grant itself controls who can use the key, but the IAM policy controls whether the caller can initiate the grant creation.

How long does it take for policy changes to take effect?

IAM policy changes typically propagate within seconds to a few minutes. However, AWS recommends waiting up to 5 minutes after making changes before testing again. If you are using the AWS CLI or SDK, ensure you are not using cached credentials that might reflect an older state. Clearing your credential cache or refreshing the session can help.

What is the difference between a grant and a key policy?

A key policy defines who can access the key at the resource level. A grant is a temporary, fine-grained permission that allows a specific principal to use the key under certain conditions. Grants are often created programmatically by AWS services. You can limit a grant to specific IP addresses or VPC endpoints, offering more dynamic control than a static key policy.