-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
s3: breaking change, cannot create bucket anymore, InvalidBucketAclWithObjectOwn #25288
Comments
we are facing this issue as well:
edit:
...but there seems to be no way to remove the |
Hi folks, for me, the solution that worked was adding the following to both buckets: |
According to the blog post announcement:
and
I believe we should improve the property validation in L2 Bucket construct to improve better user experience. For cloudfront access log bucket, this works for me per described in the blog post regarding the const logBucket = new s3.Bucket(this, 'logBucket', {
objectOwnership: s3.ObjectOwnership.OBJECT_WRITER,
autoDeleteObjects: true,
removalPolicy: RemovalPolicy.DESTROY,
}); |
@pahud I think you should pin this issue. |
Starting from April 2023, all newly created S3 buckets by default have [S3 Block Public Access](https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/) enabled and [access control lists](https://aws.amazon.com/blogs/aws/new-simplify-access-management-for-data-stored-in-amazon-s3/) (ACLs) disabled, and this prevents the default logBucket for cloudfront to be created. This PR adds the `ObjectOwnership` property to `ObjectWriter` that allows the default log bucket to be successfully created. Reference - https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/ - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-choosing-s3-bucket Closes #25288 #25291 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Set ObjectOwnership: ObjectWriter automatically if and only if: - It is not provided by the user - AccessControl ACLs are configured (only if AccessControl != PRIVATE) If the user does supply ObjectOwnership != ObjectWriter AND they try to set ACLs, we should error. `ObjectWriter` was essentially the default behavior before the change to disable ACLs by default for new buckets so though this will update existing buckets it should not cause any breakage or replacement. Closes #25288 --------- Co-authored-by: corymhall <43035978+corymhall@users.noreply.github.com>
Starting from April 2023, all newly created S3 buckets by default have [S3 Block Public Access](https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/) enabled and [access control lists](https://aws.amazon.com/blogs/aws/new-simplify-access-management-for-data-stored-in-amazon-s3/) (ACLs) disabled, and this prevents the default logBucket for cloudfront to be created. This PR adds the `ObjectOwnership` property to `ObjectWriter` that allows the default log bucket to be successfully created. Reference - https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/ - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-choosing-s3-bucket Closes #25288 #25291 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Set ObjectOwnership: ObjectWriter automatically if and only if: - It is not provided by the user - AccessControl ACLs are configured (only if AccessControl != PRIVATE) If the user does supply ObjectOwnership != ObjectWriter AND they try to set ACLs, we should error. `ObjectWriter` was essentially the default behavior before the change to disable ACLs by default for new buckets so though this will update existing buckets it should not cause any breakage or replacement. Closes #25288 --------- Co-authored-by: corymhall <43035978+corymhall@users.noreply.github.com>
I got the same message, but after sifting around the documentation for a while, found that this can be achieved with two calls (examples using NodeJS SDK)
|
I'm an AWS noob, but the bottom line for me is that I'm getting these errors while followind an AWS tutorial... https://catalog.workshops.aws/complete-aws-sam/en-US/module-4-cicd/module-4-cicd-gh/50-sampipeinit ... is this something likely to be fixed? Or does someone need to update that tutorial? |
@jstampleman I didn't look too deeply into it, but my guess is that the tutorial (or the If it's still an issue, I would suggest searching the existing issues on the SAM CLI GitHub repo, and if a relevant one doesn't exist, then submitting a new issue for it there (potentially referring back to this issue if relevant): |
This shitshow is amazing. Yes, all official AWS documents for CloudFormation still use the old syntax that fails to create anything. |
Describe the bug
Deployed S3 bucket last week into account A without issues and this week it fails on account B with a "Bucket cannot have ACLs set with "ObjectOwnership's BucketOwnerEnforced setting (Service: Amazon S3; Status Code: 400; Error Code: InvalidBucketAclWithObjectOwnership; Request ID: K97VC1M7Z0YY14A5; S3 Extended Request ID: DZGiUrXpLClhwp+7nOjoGocVx15FGQCQd6V0NGXk/YSJ3n/OTZWOIg5sNZGagfs7T0wWX2hPw6M=; Proxy: null)".
Perhaps the announcement https://www.helpnetsecurity.com/2023/02/07/amazon-s3-bucket-security/ is the reason.
Expected Behavior
I expected the buckets to be created without issue, since this worked last week.
Current Behavior
TERMINAL Output: The bucket creation fails with "1:43:11 PM | CREATE_FAILED | AWS::S3::Bucket | Servicesxxxcsvaccesslogstsm07305C09
Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting (Service: Amazon S3; Status Code: 400; Error Code: InvalidBucketAclWithObjectOwn
ership; Request ID: K97VC1M7Z0YY14A5; S3 Extended Request ID: DZGiUrXpLClhwp+7nOjoGocVx15FGQCQd6V0NGXk/YSJ3n/OTZWOIg5sNZGagfs7T0wWX2hPw6M=; Proxy: null)"
CFN Output:
Reproduction Steps
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.76.0 (build 78c411b)
Framework Version
No response
Node.js Version
v19.8.1
OS
macos
Language
Python
Language Version
Python 3.9.6
Other information
No response
The text was updated successfully, but these errors were encountered: