How do I debug an 's3:CreateBucket Access Denied' from CloudFormation

Question

I have a CloudFormation Stack created from a Serverless YAML file.

One of the resources is this:

"S3BucketWebRoot": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "samhain.today",
        "AccessControl": "PublicRead",
        "WebsiteConfiguration": {
          "IndexDocument": "index.html",
          "ErrorDocument": "404.html"
        }
      }
    }

I'm having no problems deploying the Stack files (which includes creating an S3 bucket, itself), but when the Stack starts to get built, I'm getting:

    14:38:46 UTC-0500   CREATE_FAILED   AWS::S3::Bucket S3BucketWebRoot API: s3:CreateBucket Access Denied

Problem is, the User associated with the Serverless service has, as part of its policy:

{
        "Effect": "Allow",
        "Action": [
            "s3:CreateBucket",
            "s3:PutObject",
            "s3:GetObject",
            "s3:ListBucket",
            "s3:DeleteObject",
            "s3:DeleteBucket",
            "s3:ListBucketVersions"
        ],
        "Resource": [
            "arn:aws:s3::*:*"
        ]
    }

How do I even go about debugging this? Either my Resource is wrong, or its some other user being used, but that makes no sense because they're attached to an Access Key ID.

Answer 1

I'd like to make explicit what @Dancrumb already wrote in a comment to the downvoted answer: What seemed to work for him and me was to replace fine-grained S3 permissions with a single wildcard permission:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "VisualEditor0",
        "Effect": "Allow",
        "Action": [
             "s3:*",
             ...
        ]
    }
}

I can only speculate for the reason. In an issue report for the Serverless project on Github I saw people mention that they were using a user that is tied to an account that has MFA enabled, which applies in my case, too (the account has MFA, not the user). If s3:* is too permissive for you, you may be able to restrict it "after the fact" with an additional deny segment. Unfortunately, I don't have the time to verify this theory.