S3 Block Public Access + Bucket Policy - Access Denied

0

We are running an S3 Bucket with a Cloudfront In front of it. Recently we've turned enabled block public access (All four options enabled under Individual Block Public Access settings for this bucket, but now our Fargate ECS instance is getting Access Denied doing a s3client.putobject. Images are able to be pulled through the Cloudfront URLs, s3 object are blocked, but we are unable to upload any new images from our ECS instances. How do we allow the ECS task instances to putObject

A (wide) bucket policy was added:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<aws-account>:role/<ecs-task-role>",
                    "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <OAI>"
                ]
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::<bucket-name>/*",
                "arn:aws:s3:::<bucket-name>"
            ]
        }
    ]
}

The ecs-task-role has AmazonS3FullAccess. We can manually upload to console.

Removing the following two options from block public access does again allow us to put, but then the s3 object urls are public which we want to be non-accessible.

  • Block public access to buckets and objects granted through new access control lists (ACLs)
  • Block public access to buckets and objects granted through any access control lists (ACLs)
2 Answers
0

One possible solution would be to have Fargate tasks deployed in a VPC, and then configure an S3 endpoint in that VPC. This approach is detailed in the Fargate task networking documentation. You can also reference the Amazon ECR interface VPC endpoints (AWS PrivateLink) documentation.

Kevin
answered 2 years ago
0
  1. It is recommended to go to CloudTrail and see if you can identify the API call made by the ECS task and see which one is denied, and sometimes the CloudTrail entry will give you more specific reason of the denial;
  2. Are you encrypting any S3 contents?
  3. Do you have any ACLs set?
  4. Lastly you might know this and it might be your usecase but in putting the CloudFront OAI in the policy effectively allow any random user can view, delete and update the files and even bucket in your S3, which I rarely recommend.
Jason_S
answered 2 years ago
profile picture
EXPERT
reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions