
Amazon S3 Block Public Access: Protection for Your Accounts and Buckets - ingve
https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/
======
ams6110
It's still too confusing. Too much terminology, too many settings. 3 pages and
over half a dozen screenshots to explain how to make a bucket private. Too
complicated.

Google Drive folder permissions are easier. Phrases like "Anyone with the link
can view" are understandable. Phrases like "Block public and cross-account
access to buckets that have public policies" are not.

Hide the fine-grained control in an "Advanced" panel, for those who really
need it.

~~~
privateSFacct
This again is misleading, users blaming AWS for making bucket's public.

The bucket's start out __private__.

The UI when making a bucket public comes with a big warning.

Then a big warning label is attached next to the bucket itself.

It does show I think the scale of AWS that the userbase is so large that this
isn't clear. This tool is nice because it means that a perhaps more
experienced admin can lock down an entire account a bit more so newer devs
looking to shortcut things with world public aren't as able to (which will
slow them down for sure).

~~~
ticmasta
>> he bucket's start out __private__.

Except one of the biggest initial selling points is hosting static websites,
which requires the bucket to be public. They even have a shortcut UI for
setting this up, but then they highlight this "security issue" that you have a
public bucket, which doesn't make sense.

If you've gone to the trouble to specify the bucket is a website with default
documents, etc, surely they can filter these buckets out of the ALERT! PUBLIC
BUCKET! list...

~~~
Alex3917
> Except one of the biggest initial selling points is hosting static websites,
> which requires the bucket to be public.

Maybe S3 should just be separated into buckets and websites. They can work the
same under the hood, but call them something different to prevent this issue.
Right now a lot of the new (and existing) security settings don't make any
sense in the context of websites, and having the functionality to make
websites within S3 creates security issues for everyone else.

------
fredley
I could have had this a few weeks ago, when I realised popular S3 integration
tool `django-storages` _sets all objects ' ACL as public-read by default_:

[https://django-
storages.readthedocs.io/en/latest/backends/am...](https://django-
storages.readthedocs.io/en/latest/backends/amazon-S3.html)

~~~
cbg0
Can't really fault Amazon or the Django library for you not reading the docs.

~~~
geofft
I am 100% willing to fault software for bad defaults regardless of how they
document those defaults.

~~~
nscalf
Absolutely agree. Telling people of your bad design is still bad. Especially
when "telling people" happens in a flood of other noise, like one line in
documentation on a whole tool.

~~~
Alex3917
> Telling people of your bad design is still bad.

IIRC the person who took over maintenance and added that warning isn't the one
who created the tool.

------
code4tee
This is a useful and much needed update. Know lots of stories where people got
caught off guard by ACLs setting things public that they thought were private.

Usual scenario is that the bucket is set as “private” and you think it’s
private but realize some app or script has set the ACL for objects to
“public.”

~~~
privateSFacct
"got caught off guard by ACLs setting things public that they thought were
private."

A lot of these stories are written in this way where Amazon's ACL's "set thing
public" when the user wanted things private.

To add a little reality here:

Amazon defaults are generally to _private_.

You get no network ingress to an instance by default (zero). You have no
username/password login by default (zero) - you need to use SSH with a public
key. S3 buckets are resource owner and aws account owner only to start.

My one issue - I wish they made buckets with no permissions by default, make
the account owner add themselves or resource owner add themselves.

What is happening is despite LOTS of docs out there, users find it easier
during development, quick integration to do things like WORLD readable. This
is BY FAR the most common issue, USERS (not amazon) setting things to totally
public by choice.

I've had folks tell say:

* It will only be public for a few days / short period of time while we work out X (once everything is used to public access it actually is HARDER to switch to secure access).

* I can't be bothered to learn IAM permissions (one of the most useful features AWS has for example relative to a place like google).

I like this new thing not because amazon is at fault, but because users are
super lazy, and now some annoying "admin" can block them from making things
totally public when they want to share with a partner, separate project etc.

So a good feature.

Now make S3 bucket's with NO permissions by default (not even creator /
account owner) so folks can learn a bit of AWS right away to get going.

~~~
dylan604
This is where I have actually come to appreciate SELinux. A newer dev comes
along and makes a folder in the document root to 777 thinking that will solve
their problems. SELinux still needs to explicitly allow that folder to be
writable. That slows them down long enough to come find me, and then we get to
have the proper conversation about what needs to happen. A folder in the
document root with 777 scares the crap out of me

~~~
morpheuskafka
Do you know of any good intro to SELinux guides? I'm hoping to use it to lock
down webroots to prevent other users from modifying them even if the user
messes up all the permissions via SFTP.

~~~
dylan604
Sadly, no. I only play a sysadmin on TV ;-) I don't fully feel like I have
groked SELinux, but when things behave unexpectedly, it takes me less and less
time to remember to check if SELinux is involved. I have at least come to
accept that it is there to help, and it has saved me from doing some really
dumb things.

Things to know is that there is a specific setting to allow httpd to write to
a folder. There is a way to list files `ls -Z` that shows you the SELinux
Context for files/folders. httpd error_log entries will just give permission
denied errors, but if you feel like the perms are correct, SELinux will
probably be why you're getting denied. That's how I started learning. One
error at a time.

------
morpheuskafka
If people using AWS for your organization can't be bothered to take a few
minutes to RTFM in its entirety (AWS has excellent documentation, compare to
Azure's docs.microsoft.com behemoth of confusion), they shouldn't have access
to reconfigure you're entire cloud infrastructure. Buckets are sensible
private by default. If you don't know what you're doing, leave them that way.

~~~
kderbyma
This is sarcasm right? AWS doc's are okay, but not great. Honestly, their
documents are pretty piss poor. They have contradicting statements depending
on what tool, they have 100 exceptions for integrating their own toolchain,
and the perspective and context is never clear. Sure...their basic stuff is
well documented....but it's constantly changing and their system isn't
versioned in a way that is easy to upgrade or transition legacy systems.

------
tombrossman
Related question, anyone know how to grant access to S3 objects via CloudFront
_only_ , since CloudFront bandwidth usage is cheaper than S3 objects accessed
directly?

I've got it working for top level documents using Origin Access Identity, but
subfolders (example.com/test/index.html) doesn't work. I'm surprised this use
case isn't better documented because it saves you money and you don't need to
make your bucket public.

~~~
mvanbaak
[https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-
content-restricting-access-to-s3.html)

With a bucket policy you can use wildcards etc to provide access to all or
parts of the bucket content.

------
privateSFacct
My two wishes:

Totally private (no permission) buckets by default.

Some additional support for common usecases that drive the shortcut to public
readable (often sharing internally for a project). Not sure if this would be a
good thing, but folks are used to defining a group, adding users to a group
(project / departments etc) in enterprise context, AWS supports this with IAM,
but I wonder if surfacing a UI / something here might simplify this in some
way.

~~~
jeffbarr
Please feel free to track me down and email those use cases to me.

~~~
privateSFacct
Hi Jeff,

I'm not sure of the answer, but:

Bob says I'd like to play around with data x on S3, or grab report z on S3.
They are used to the Dropbox / drive / box etc model. That's often invite by
email or allow *@domain.com permission. But how does this work in S3, how do
you invite someone, how do they self provision their credentials without admin
involvement etc? For a non aws/s3 user? One thing you can do, make bucket
world readable.

Big user base plus more stuff collecting in S3 from various systems seems to
drive some risk, not sure how s3 solves for above or if it should (email or
domain invite, self provisioning of credentials if not on platform etc). Tie
into workdocs somehow? Push into competitor tools?

This issue also comes up in the cross account / org situation. Want to invite
someone outside of org to read data etc. Tools to do this, but it takes more
work than folks are used to with other approaches. Pretty soon something is
world readable.

API side for developers works great.

Be curious if others had use cases that create gravity towards world readable
- because s3 by default is not, but a relatively high number of people end up
there for some reason. Be interesting to try to give them what they want in
addition to lockdown tools.

------
dorianm
Hmmm
[https://www.google.com/search?q=site%3As3.amazonaws.com&en=](https://www.google.com/search?q=site%3As3.amazonaws.com&en=)

Combine it with the right keywords and you can find anything

~~~
bdcravens
Everything I found was either a PDF file (common use case when you'd want the
bucket to be public) or an html file in a bucket-hosted website (another use
case where public is the correct behavior)

~~~
mgliwka
Try this:
[http://buckets.grayhatwarfare.com](http://buckets.grayhatwarfare.com)

~~~
dorianm
Nice, I just searched for .env and saw multiple people AWS secret keys

