S3 Bucket策略能否覆盖IAM策略？及相关权限异常问题咨询

安全阿岳

2026-5-8

Why Your S3 Bucket Policy Isn't Blocking EC2 Access

Great question! Let's break this down clearly—this isn't about Bucket policies being unable to override IAM policies (they absolutely can, thanks to AWS's explicit Deny priority), but rather a small but critical mistake in how you defined your Bucket policy's Resource field.

The Root Cause: Incorrect Resource ARN

When you run aws s3 ls ananda-demo-bucket-1 from your EC2 instance, you're calling the s3:ListBucket API operation. This operation requires permissions targeted at the bucket itself, not the objects inside it.

Your current policy uses this resource ARN:

arn:aws:s3:::ananda-demo-bucket-1/

The trailing slash here tells AWS you're targeting objects within the bucket (specifically, all objects under the root prefix), not the bucket resource itself. So your Deny rule doesn't apply to the s3:ListBucket action—leaving the AmazonS3ReadOnlyAccess policy's Allow for that action intact.

Fixing the Bucket Policy

To block all actions on both the bucket and its contents, you need to include two resource ARNs in your policy:

The bucket's base ARN (for bucket-level operations like ListBucket, CreateBucket, etc.)
The bucket's object path ARN (for object-level operations like GetObject, PutObject, etc.)

Here's the corrected policy:

{
  "Action": "s3:*",
  "Effect": "Deny",
  "Resource": [
    "arn:aws:s3:::ananda-demo-bucket-1",
    "arn:aws:s3:::ananda-demo-bucket-1/*"
  ],
  "Principal": "*"
}

How AWS Permission Evaluation Works

Just to confirm: AWS follows a strict priority order for permissions:

Explicit Deny (from any IAM policy, Bucket policy, or session policy) always takes precedence over any Allow.
If no Deny exists, then check for Explicit Allow from any policy.
If neither exists, access is denied by default.

So once you fix your resource ARNs, the Deny will override the IAM role's Allow, and your EC2 instance won't be able to list the bucket contents anymore.