|
|
|
|
|
by bostik
3209 days ago
|
|
> Default settings are usually NO public read, and it actually takes more work to make stuff publicly readable on S3 than to just leave it as private. While true, and a very sensible default, this misses one crucial point. Setting granular permissions for an S3 bucket is hideously difficult. Want to limit access to a whitelisted set of users or origins? Write a bucket policy. This is where the UI completely fails. 0: The policies can become awfully difficult to understand even for straightforward use cases. 1: You can have policies with sensible rule sets, but the S3 UI doesn't allow to pick-and-attach any of them. 2: The "permissions" tab has a very convenient and extremely dangerous option as the top item: "allow access for any logged in user" I'll let the last one sink in. It's not "any logged in user in MY organisation", it's really "ANY logged in AWS user". Putting the bucket essentially world-readable by accident is far too easy. |
|
Most of my projects use either totally restricted buckets, or buckets with access to a particular IAM, which is basic, but works.