Static website deploy does not work for SPA projects anymore

[moein-tropee]

Description

I've been using lift for the past 6 months and it's a great plugin (thanks to all the maintainers).
After updating to lift 1.12.0 and serverless 3.1.0 I noticed a strange behaviour which appears to be related to one of aws-cdk subpackages (I can not pinpoint which one).
For some reason the policy of the bucket is not being set correctly anymore which causes cloudfront to return a 403 instead of rendering index.html when accessing any route (which is needed for SPA projects).

How to Reproduce

Create a simple project with serverless

yarn init
yarn add -D serverless serverless-lift
mkdir dist
echo hello > dist/index.html

Put the following in serverless.yml

service: lift-test
frameworkVersion: '3'
useDotenv: true
variablesResolutionMode: 20210326

provider:
  name: aws
  region: eu-west-1
  stage: ${opt:stage}
  stackTags:
    STACK: ${self:service}
    REGION: ${self:provider.region}

constructs:
  vue:
    type: static-website
    path: dist

plugins:
  - serverless-lift

And run yarn sls deploy --stage dev
Once deploy is done you can see access the cloudfront domain (xyz.cloudfront.net/whatever) and you get 403 instead of hello

Additional Information

From what I understand the issue is coming from incorrect permissions set on the bucket.

For the latest version which SPA does not work anymore

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XYZ"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::test-dev-vuebucketXYZ/*"
        }
    ]
}

For the old one that works

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XYZ"
            },
            "Action": [
                "s3:GetObject*",
                "s3:GetBucket*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::trope3-webapp-dev-vuebucketXYZ",
                "arn:aws:s3:::trope3-webapp-dev-vuebucketXYZ/*"
            ]
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XYZ"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::trope3-webapp-dev-vuebucketXYZ/*"
        }
    ]
}

[adriencaccia]

Per the AWS support::

If a user doesn't have s3:ListBucket permissions, then the user gets Access Denied errors for missing objects instead of 404 Not Found errors.

A potential fix could be to find a way to re-attach the s3:ListBucket permission to the bucket policy generated by CDK, now that we use the default OAI, as shown here in the 1.12.0 release.

[mnapoli]

Damn, this is annoying. Thanks for the report and digging in.

I'll probably have time to look into it this weekend, but if anyone wants to send a PR that addresses that before I'd love to merge it!

[t-richard]

So the OAI currently is too restrictive ? Because of that, Cloudfront gets a 403 from S3 instead of a 404 which means this never gets a chance to apply.

As those are static files, I guess broader permissions are not an issue.