KMS GenerateDataKey Write Permission Fix

The Incident (What Does the Error Mean?)

You will see one of these in CloudTrail or your application logs:

An error occurred (AccessDeniedException) when calling the PutObject operation:
User: arn:aws:sts::123456789012:assumed-role/my-app-role/session
is not authorized to perform: kms:GenerateDataKey
on resource: arn:aws:kms:us-east-1:123456789012:key/mrk-abc123

or from the AWS SDK:

AccessDeniedException: User is not authorized to perform kms:GenerateDataKey
Status Code: 400
Request ID: a1b2c3d4-...

Immediate consequence: Every write to any SSE-KMS encrypted S3 bucket, EBS volume, RDS instance, or Kinesis stream tied to this key is dead. Uploads return 403. ETL pipelines stall. Backup jobs silently fail if error handling is weak.

The Attack Vector / Blast Radius

This is not a hacker exploit — this is a misconfigured least-privilege rollout that kills availability. The blast radius depends on what the principal does:

Why it's subtle and dangerous: kms:GenerateDataKey is required for the write path only. A principal with only kms:Decrypt can read existing objects but cannot write new ones. Teams often discover this in production after rotating to a new CMK or tightening an existing policy — reads keep working, masking the breakage until the first write attempt.

If you over-correct by granting kms:* to fix this fast, you've now given the principal kms:DisableKey, kms:ScheduleKeyDeletion, and kms:PutKeyPolicy — a catastrophic over-privilege that an attacker with access to that role can leverage to destroy your encryption keys.

Prevention in CI/CD

1. Checkov — catch missing GenerateDataKey before deployment:

Checkov rule CKV_AWS_7 covers KMS key rotation but doesn't catch this specific gap. Write a custom check or use cfn-python-lint with a custom rule:

# .checkov/custom_checks/kms_generate_data_key.py
# Flag any IAM policy that grants s3:PutObject on an encrypted bucket
# without a corresponding kms:GenerateDataKey in the same statement block

2. OPA/Rego policy for Terraform plan validation:

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_iam_policy"
  actions := resource.change.after.policy.Statement[_].Action
  "s3:PutObject" == actions[_]
  not contains_generate_data_key(actions)
  msg := sprintf("IAM policy '%v' allows s3:PutObject but is missing kms:GenerateDataKey", [resource.address])
}

contains_generate_data_key(actions) {
  actions[_] == "kms:GenerateDataKey"
}

3. AWS IAM Access Analyzer: Enable it in every account. It will flag policies that allow S3 write actions without corresponding KMS permissions when the bucket has SSE-KMS enforced via bucket policy (aws:SecureTransport + s3:x-amz-server-side-encryption).

4. Enforce SSE-KMS + deny unencrypted puts at the bucket policy level — this makes the kms:GenerateDataKey gap surface immediately in dev/staging rather than silently in prod:

{
  "Sid": "DenyUnencryptedObjectUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"
    }
  }
}

This forces every writer to use the specific CMK — and if they're missing kms:GenerateDataKey, they'll fail fast in your pipeline, not in production.