I was using Cloud-Front to access files in my S3 bucket and update the files. I disable Cloud-Front now, however i cannot access those files directly through S3 now.
Also, when i try to set permissions on items in the bucket i receive a message that access was denied. I don't have such problem with items updated directly through S3.
How can i enable access to files in my bucket directly though s3?
I had the same problem: Files created with Origin Access Identity weren't readable by the host account (or any user accounts) and couldn't be accessed via CLI, Lambda or the Console.
My solution was to set a header on the client request that allows control of the files by the bucket owner.
x-amz-acl=bucket-owner-full-control
This shouldn't require changes to your Cloudfront distribution. All x-amz-* headers should be passed through automatically.
I complemented this solution with a bucket policy that requires this header. So, people can't hack my client and upload files that I can't manage. The following is added to the policy statement object allowing s3:PutObject by the Origin Access Identity:
"Condition": { "StringEquals": { "s3:x-amz-acl": [ "bucket-owner-full-control" ] } } The cause is described in Managing Access with ACLs.
For example, if a bucket owner allows other AWS accounts to upload objects, permissions to these objects can only be managed using object ACL by the AWS account that owns the object.
The only way I found to manage ACLs created by the Origin Access Identity is to set the x-amz-acl header at object creation time.
An alternative to Waylon Flinn's answer is to add / overwrite the x-amz-acl header in a Lambda@Edge function. Something along these lines in nodejs:
exports.handler = (event, context, callback) => { const { request } = event.Records[0].cf; const { headers } = request; headers['x-amz-acl'] = [{key: 'x-amz-acl', value: 'bucket-owner-full-control'}]; callback(null, request); }; The advantage is that you no longer need that policy Waylon writes in his answer since you always set the x-amz-acl header yourself in your own trusted environment. The downside is that Lambda@Edge comes with its own complexity, quirks, and extra costs. It is up to you to decide which approach is better for your use case.
Lambda@Edge was not available at all when Waylon wrote his answer back in 2016. It became generally available on Jul 17, 2017 (almost an year later): Lambda@Edge now Generally Available.
Having had the issue a couple of times. The solution is Creating a CloudFront Origin Access Identity and adding it to Your Distribution when creating CF.
Distribution->Streaming->Distribution Settings->Edit Restrict Bucket Access: Yes Origin Access Identity: Use existing (you may need to setup) Grant Read Permissions on Bucket: Yes Restrict Viewer Access (Use Signed URLs): Yes Trusted Signers: Self ... Used default for rest ...
I hope that helps
