Revisit the idea of using S3 ACLs

[danlamanna]

From https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html

For the majority of modern use cases in S3, we recommend that you disable ACLs by choosing the bucket owner enforced setting and use your bucket policy to share data with users outside of your account as needed. This approach simplifies permissions management and auditing.

Moving away from S3 ACLs would allow us to follow S3 best practices and keep feature parity while removing the code/configuration around object ownership.

[satra]

@danlamanna - it would be good to add where this would be applied.

[danlamanna]

Given how much AWS steers people away from it, I'd like to have a skeptical eye towards using a legacy access control mechanism in any of our buckets. I'm not sure that any of our use cases of object storage demands very different permissions on a per object basis that we couldn't otherwise satisfy by using wildcard policies e.g. "Resource": ["arn:aws:s3:::bucketname/secretstuff/*"].

[satra]

there are two different types of buckets and operations.

1. the public bucket: this has public read, but signed url write
2. the embargoed bucket: this has signed url read and write as far as i know

we are controlling everything through the dandi api layer rather than through ACLs for individuals as far as i know. hence my curiosity as to where ACLs actually come into play in dandi.

[danlamanna]

Oh I misunderstood your original comment. ACLs are enabled on our buckets but I don't think they're used in any meaningful way. There's a handful of places where we have to deal with this (see https://github.com/search?q=org%3Adandi+bucket-owner-full-control&type=code) that just complicates our policies for no benefit that I'm aware of.

[satra]

just complicates our policies for no benefit that I'm aware of.

trimming away complications that don't benefit us sounds good to me :)