Notice: S3 - Changes to Defaults (Block Public Access and ACL's)

[ewbankkit]

Starting in April 2023, Amazon S3 will introduce two new default bucket security settings by automatically enabling S3 Block Public Access and disabling S3 access control lists (ACLs) for all new S3 buckets.

Announcement
Blog post
FAQ

Relevant resources:

• aws_s3_bucket
• aws_s3_bucket_acl
• aws_s3_bucket_ownership_controls
• aws_s3_bucket_public_access_block

Relates #22069
Relates #6607

---

Terraform AWS Provider Impact

This section will detail the impact of the upcoming AWS S3 security changes on the Terraform AWS Provider.

Summary

The impending S3 security changes will not require breaking changes to v3 or v4 of the Terraform AWS provider. However, some previously valid S3 bucket ACL configurations will begin returning errors for net-new buckets. Existing buckets (and their corresponding terraform configuration) are not impacted.

ACL Changes

ACLs can be defined either directly on the aws_s3_bucket resource, or via the standalone aws_s3_bucket_acl resource. This is true in both v3 and v4 or the provider, though the acl attribute on the S3 bucket resource was officially deprecated in v4.

Inline:

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
  acl    = "private"
}

Standalone Resource:

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
}

resource "aws_s3_bucket_acl" "example" {
  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

While existing buckets are not impacted by the impending security changes, the following configuration patterns are impacted for net-new buckets:

1. Inline acl where the value is not private.
2. Standalone aws_s3_bucket_acl resource with default security settings.

Inline acl where the value is not private

In both v3 and v4 of the provider, the inline acl attribute defaults to private when unset. Passing a value of private on bucket creation continues to work post-security changes, but any other value requires the default object ownership settings be changed in the same request. Currently, there is no way to do this via the aws_s3_bucket resource. Adoption of the standalone aws_s3_bucket_acl resource, paired with the aws_s3_bucket_public_access_block and aws_s3_bucket_ownership_controls resources allows the default security settings to be adjusted as necessary.

Existing Configuration

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
  acl    = "public-read"
}

Error

Error: creating Amazon S3 (Simple Storage) Bucket (my-bucket): InvalidBucketAclWithObjectOwnership: Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting

Alternative Configuration

This configuration splits bucket and ACL creation into separate API calls, with the requisite block public access and object ownership API calls in between.

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
}

resource "aws_s3_bucket_public_access_block" "example" {
  bucket = aws_s3_bucket.example.id

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

resource "aws_s3_bucket_ownership_controls" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "example" {
  depends_on = [
	aws_s3_bucket_public_access_block.example,
	aws_s3_bucket_ownership_controls.example,
  ]

  bucket = aws_s3_bucket.example.id
  acl    = "public-read"
}

Standalone aws_s3_bucket_acl resource with default security settings

With the default security settings unchanged, any attempt to set an ACL on an existing bucket via the standalone ACL resource will fail, even if the value is private.

Existing Configuration

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
}

resource "aws_s3_bucket_acl" "example" {
  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

Error

Error: error creating S3 bucket ACL for my-bucket: AccessControlListNotSupported: The bucket does not allow ACLs

Alternative Configuration

With the new default security settings, a private ACL definition can likely be removed completely as the default security settings already ensure public access is restricted upon bucket creation.

However, if a private ACL is explicitly required, the following configuration splits bucket and ACL creation into separate API calls, with the requisite object ownership API call in between.

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"
}

resource "aws_s3_bucket_ownership_controls" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "example" {
  depends_on = [aws_s3_bucket_ownership_controls.example]

  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

For use cases requiring non-private ACLs, an additional aws_s3_bucket_public_access_block resource would also be required, as documented in the inline use case above.

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[Zordrak]

It would be very useful for an acl object that sets the acl to private to noop and succeed rather than fail when ownership controls are BucketOwnerEnforced. We are now having to optionally count-off the acl resource if ownership_controls == "BucketOwnerEnforced"

[mattiasnixell]

Hello, I'm trying to deploy S3 with ownership and private ACL (the last alternative suggestion):

resource "aws_s3_bucket" "state" {
  bucket = "${var.name_prefix}-terraform-state"
}

resource "aws_s3_bucket_ownership_controls" "state" {
  bucket = aws_s3_bucket.state.id
  rule {
    object_ownership = "BucketOwnerEnforced"
  }
}

resource "aws_s3_bucket_acl" "state" {
  depends_on = [
    aws_s3_bucket_ownership_controls.state,
  ]

  bucket = aws_s3_bucket.state.id
  acl    = "private"
}

However, the aws_s3_bucket_acl still gives "AccessControlListNotSupported: The bucket does not allow ACLs" error after adding the aws_s3_bucket_ownership_controls resource.

Removing aws_s3_bucket_acl seems to work. However, I'm afraid that might unexpectedly affect old terraform states using the same module. That's why I want to define it explicitly.

EDIT: I had the wrong ownership configuration. It should be BucketOwnerPreferred, not BucketOwnerEnforced.

[jpriebe]

However, the aws_s3_bucket_acl still gives "AccessControlListNotSupported: The bucket does not allow ACLs" error after adding the aws_s3_bucket_ownership_controls resource.

Removing aws_s3_bucket_acl seems to work. However, I'm afraid that might unexpectedly affect old terraform states using the same module. That's why I want to define it explicitly.

Hi, @mattiasnixell - I hit this error today with nearly identical code. We have a module that creates S3 buckets in accordance with company policy. It defines the aws_s3_bucket_ownership_controls and the private aws_s3_bucket_acl (although we did not have the depends_on in our ACL).

The behavior I saw was that the first run of the pipeline would fail with the AccessControlListNotSupported error. I was able to just plan and apply again, and the ACL applied cleanly. Presumably that is because the bucket ownership controls were applied in the first apply.

I should mention that the behavior was intermittent, suggesting a possible race condition.

This would suggest that the depends_on should work (unless you need some arbitrary time interval to elapse between the creation of the ownership controls and the ACL). I was about to add the depends_on to our team's S3 bucket module, but then I found your post, which makes me question the approach.

I do notice that your example uses BucketOwnerEnforced, while the example uses BucketOwnerPreferred. I think that might be the problem you are encountering. I don't think you can set an ACL with BucketOwnerEnforced.

[wxnc-haffi]

I'm trying to follow the examples here:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_logging

Which indicate that an ACL set to log-delivery-write is the right thing to do, does this also require a aws_s3_bucket_public_access_block resource in addition to the aws_s3_bucket_ownership_controls required for ACL?

edit: To clarify my confusion is why delivering access logs from within the same account would require me to allow public ACL's.

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.