(aws-cloudfront-origins): S3Origin needs s3:ListBucket permission for CloudFront to return 404

[aaronlna]

Reading thru the S3Origin construct it appears the only permission granted to the associated CloudFront distribution is s3:GetObject. However, without s3:ListBucket, CloudFront has no way of returning a 404 response to callers and instead returns HTTP 403 Forbidden.

Use Case

It would be nice for S3Origin construct to provide all the necessary permissions for an associated CloudFront distribution to respond via HTTP. After using this construct its unintuitive to have my CloudFront distribution responding to callers with 403 for resources that are otherwise missing per HTTP spec.

Proposed Solution

Add s3:ListBucket in addition to the current s3:GetObject for the resource policy of the S3 bucket for given CloudFront distribution.

[robertd]

@njlynch Most likely affected by changes introduced in cc28312

[njlynch]

@robertd - Correct!

@aaronlna - See more details in the pull request description for #13087. Having the OAI granted List* leads to (potentially) the complete contents of the bucket being listable when navigating to the distribution root. This was generally seen as undesirable behavior and removed in 1.90.0.

There is a work-around, which is to explicitly create the OAI and grant access yourself:

// Before
const bucket = new s3.Bucket(this, 'Bucket');
const s3Origin = new origins.S3Origin(this, 'S3Origin', { bucket });

// After
const bucket = new s3.Bucket(this, 'Bucket');
const originAccessIdentity = new cloudfront.OriginAccessIdentity(this, 'OAI');
bucket.grantRead(originAccessIdentity);
const s3Origin = new origins.S3Origin(this, 'S3Origin', { bucket, originAccessIdentity });

The other work-around is to redirect the 403s to 404s.

const dist = new cloudfront.Distribution(this, 'Dist', {
  ...
  errorResponses: [{
    httpStatus: 403,
    responseHttpStatus: 404,
    responsePagePath: '404.html', // Optional, if you want to redirect to a specific 404 page in the bucket.
  }],

Finally, we can consider adding in an option to grant the List permissions back in, with sufficient documentation and warning about potentially exposing the bucket contents if a default root object is not set.

[dtabuenc]

Why not grant the permissions by default if a root object is set? The current default is pretty unexpected. A lot of people are trying to troubleshoot permissions issues when really they should be seeing 404s. At the very least there should be a convenience method or property added to enable the behavior probably most people expect and want.

[WtfJoke]

I just stumbled over the same issue when we activated WAF in our cloudfront distribution, as we couldn't distinguish between 403 responses from malicious blocked calls and 403 from legitimate users (which should have been a 404 to redirect users in a SPA).

I've opened #26830 (with some more details) but found this existing issue afterwards.

It would be great if you could configure this.