Summary

The web content discusses the author's experience and confusion with AWS CloudFront distribution setup due to a requirement for S3 bucket ACL access for logs, despite the general advice against using ACLs for bucket security.

Abstract

The author encountered an error while setting up a CloudFront distribution, which stated that the specified S3 bucket for CloudFront logs did not enable ACL access. This is at odds with the best practice of using bucket policies instead of ACLs for securing S3 buckets. The author notes that AWS's messaging is confusing because it suggests enabling ACLs, which contradicts their own recommendation to avoid ACLs. The author provides screenshots and links to AWS documentation, highlighting the issue that arises when CloudFront requires ACLs for logging, potentially granting full control over the logs to the awslogsdelivery account. This could lead to the manipulation or deletion of log files. The author suggests that AWS should update CloudFront logging to work with bucket policies and advises users to consider replicating logs to a separate, secure location to mitigate the risk of log tampering.

Opinions

The author believes AWS's current CloudFront logging implementation is flawed and outdated, as it relies on S3 bucket ACLs instead of more secure bucket policies.
The author is critical of AWS's messaging, finding it contradictory and confusing, especially since AWS recommends against using ACLs but simultaneously requires them for CloudFront logging.
The author is concerned about the security implications of the awslogsdelivery account having full control over the log files, as this could lead to unauthorized alterations or deletions.
The author recommends that users should not rely on ACLs for securing S3 buckets and should instead use bucket policies that limit permissions appropriately.
The author suggests that AWS should address this issue by allowing CloudFront to work with bucket policies that provide write-once access for log files, enhancing security and aligning with best practices.
The author advises users to consider archiving log files to a separate location, such as Amazon Glacier, to maintain a backup in case of log file manipulation or loss.

Resource handler returned message: “Invalid request provided: AWS::CloudFront::Distribution: The S3 bucket that you specified for CloudFront logs does not enable ACL access”

Confusing AWS implementation and messaging and questions about the implementation…

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Bugs | AWS Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

While trying to create a CloudFront distribution I got this error:

Resource handler returned message: “Invalid request provided: AWS::CloudFront::Distribution: The S3 bucket that you specified for CloudFront logs does not enable ACL access”

In general, you should never use ACLs to secure an S3 bucket. You should use a bucket policy.

So why is this error message from AWS suggesting that ACL access need to be enabled. Is that required by CloudFront? Let’s take a look.

By default this is what you get for an S3 bucket under permissions:

Configuring and using standard logs (access logs)

Use log files to get information about user requests for your objects.

docs.aws.amazon.com

I wrote about this change to S3 bucket ownership here:

Who Owns The Objects in your AWS S3 Buckets?

ACM.196 The default for Object Ownership changed in April 2023

medium.com

When you turn this on for CloudFront you get all kinds of warnings:

This is really all quite confusing and AWS should probably fix CloudFront logging to work with a proper bucket policy and no ACLs.

Apparently this confusing behavior started in April 2023.

When you create or update a distribution and enable logging, CloudFront uses these permissions to update the ACL for the bucket to give the awslogsdelivery account FULL_CONTROL permission. The awslogsdelivery account writes log files to the bucket. If your account doesn't have the required permissions to update the ACL, creating or updating the distribution will fail.

Full control? Like the ability to delete or alter the logs after writing them?

Not good. I suggest you replicate the logs to a bucket or location where the logging service cannot permanently delete your logs, if I understand this correctly.

Then over on this other page, AWS recommends not using ACLS. So why do you have to enable them if you’re not supposed to use them? More confusion:

Restricting access to an Amazon S3 origin

Restrict access to an Amazon S3 origin with Amazon CloudFront origin access control (OAC).

docs.aws.amazon.com

I also hope that AWS fixes this sooner than later to use a proper bucket policy in which you can give the service write once only access to log files. Even if you turn on versioning, the logging service has full access to the bucket so it could delete the versions. If you move the logs to an alternate location like archive them to glacier or something then you will have a backup in case something goes awry.

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab