Skip to content

Disable S3 ACLs by default in AWS S3 Adapter #1874

Open
@Korbeil

Description

@Korbeil

Summary

AWS has officially deprecated the use of Access Control Lists (ACLs) and now disables them by default for all new S3 buckets as of April 2023. The current Flysystem S3 adapter should align with AWS security best practices by not applying ACLs by default and only enabling them when explicitly requested by the user.

Background

AWS made significant security changes to S3 in April 2023:

  • S3 ACLs are now disabled by default for all new buckets
  • AWS recommends using bucket policies and IAM policies instead of ACLs
  • ACLs are considered legacy and less secure than policy-based access control

Reference: AWS announcement

Current Issue

The current S3 adapter in Flysystem may still be applying ACLs by default, which:

  1. Goes against AWS current security recommendations
  2. May cause errors with new S3 buckets that have ACLs disabled
  3. Forces users into potentially less secure configurations
  4. Provoke issues with cross-account S3 bucket with IAM policies (which can conflict with auto-declared ACLs that Flysystem bundle declares)

Proposed Solution

Option 1: Disable ACLs by default

  • Remove any default ACL configuration from the S3 adapter
  • Only apply ACLs when explicitly configured by the user
  • Add clear documentation about when and how to enable ACLs if needed

Option 2: Make ACL usage explicit

  • Add a configuration option like use_acls: false by default
  • Require users to explicitly set use_acls: true if they need ACL functionality
  • Issue deprecation warnings when ACLs are used with a non major release until next major version

Benefits

  • ✅ Aligns with AWS security best practices
  • ✅ Reduces security risks for users
  • ✅ Prevents errors with new S3 buckets
  • ✅ Encourages modern access control patterns
  • ✅ Maintains backward compatibility for users who need ACLs

Breaking Change Considerations

This would be a breaking change for users currently relying on default ACL behavior. Consider:

  • Implementing in a major version release
  • Providing clear migration documentation
  • Adding configuration options for backward compatibility

Additional Context

AWS now recommends using:

  • IAM policies for user/role-based access
  • S3 bucket policies for resource-based access
  • S3 Object Ownership settings instead of ACLs

The few use cases that still require ACLs should be explicit opt-ins rather than defaults.


References:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions