Error: AccessDenied for SSE-KMS — When Encryption Breaks S3 Access

#aws#s3#devops#cloud

KMS permissions and key policies that stop data cold.

Problem

It’s 2 AM, production alarms are firing, and every attempt to read or write to S3 comes back with:

<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
</Error>

But this isn’t your ordinary bucket policy issue. This time, the bucket has SSE-KMS (Server-Side Encryption with AWS KMS) enabled — and the missing link is key permissions. To leadership, it looks like S3 is down. In reality, it’s KMS standing in the way.

---

Clarifying the Issue

When an S3 bucket is encrypted with SSE-KMS, every request has to call AWS KMS to use the encryption key. That means your IAM user or role needs:

• Permission to use the bucket and
• Permission to use the KMS key

If either one is missing, S3 returns AccessDenied.

Common causes:

• The bucket policy allows access, but the KMS key policy doesn’t.
• Cross-account roles don’t have explicit kms:Decrypt or kms:Encrypt.
• Applications using temporary credentials forget to include KMS permissions.
• Default encryption switched from SSE-S3 to SSE-KMS without updating IAM policies.

It’s not an S3 outage — it’s a permissions mismatch between S3 and KMS.

---

Why It Matters

SSE-KMS makes data secure, but it also introduces a second choke point:

• False outages: Teams burn time thinking S3 is broken.
• Operational delays: Data pipelines stall when KMS denies access.
• Security risks: Developers overcompensate by loosening key policies too much.
• Audit failures: Lack of governance around KMS permissions undermines compliance.

The problem isn’t encryption itself. It’s forgetting that KMS keys require their own governance, just like buckets.

---

Key Terms

• SSE-KMS: Server-Side Encryption with AWS KMS, where S3 encrypts objects with a KMS-managed key.
• KMS Key Policy: A resource policy attached to a KMS key defining who can use it.
• kms:Encrypt / kms:Decrypt: Core actions needed to write to and read from an SSE-KMS–protected bucket.
• Cross-Account Access: When roles or users from one AWS account need to access resources in another.

---

Steps at a Glance

1. Confirm the AccessDenied error is tied to SSE-KMS.
2. Check bucket encryption settings.
3. Verify IAM permissions include KMS actions.
4. Review and adjust the KMS key policy.
5. Test with CLI and enforce governance going forward.

---

Detailed Steps

1. Confirm the AccessDenied Error is Tied to SSE-KMS
Check if the bucket has KMS encryption enabled:

aws s3api get-bucket-encryption --bucket my-bucket

Look for "SSEAlgorithm": "aws:kms".

---

2. Check Bucket Encryption Settings
Ensure the correct key is configured:

aws s3api get-bucket-encryption --bucket my-bucket \
  --query "ServerSideEncryptionConfiguration.Rules[].ApplyServerSideEncryptionByDefault"

---

3. Verify IAM Permissions Include KMS Actions
Your IAM role or user needs explicit permissions:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Note: For best practice, replace ` with the specific ARN of your KMS key. ` is often used in quick fixes but is less secure.
The kms:GenerateDataKey action is required because S3 uses KMS to generate the unique data key that encrypts each object.

---

4. Review and Adjust the KMS Key Policy
Even with IAM permissions, the KMS key itself must trust your principal:

{
  "Sid": "AllowAppRoleUseOfKey",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/MyAppRole" },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

---

5. Test with CLI and Enforce Governance Going Forward
Upload and download a test file:

aws s3 cp ./test.txt s3://my-bucket/
aws s3 cp s3://my-bucket/test.txt ./download.txt

Enforce governance:

• Standardize key usage per environment.
• Require explicit principals in KMS key policies.
• Monitor CloudTrail for AccessDenied on KMS actions.

---

Conclusion

The AccessDenied for SSE-KMS error isn’t an S3 outage — it’s KMS refusing to play ball. By confirming encryption settings, validating IAM permissions, fixing KMS key policies, and enforcing governance, you turn blocked access into secure, reliable operations.

Encryption is power. Without governance, it becomes a wall. With the right permissions in place, it’s the difference between an AccessDenied alert and a good night’s sleep.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.