- Now let's review a demo
of creating a bucket policy for public read access.
So we're back in S3 taking a look at the
AWS Fundamentals 2nd Edition bucket
that we created earlier.
Here's an object that we uploaded earlier.
And so, if we needed this bucket
to be publicly accessible,
if this bucket were meant to house
some type of information that you wanted to
disseminate to the public at large,
to anonymous users,
then there are a couple of ways to go about that.
If we were to go to permissions,
we could use access control lists,
and we could say that
everyone is allowed to do certain things.
We could say everyone is allowed to list,
and everyone is allowed to read,
and those are fairly coarse grained.
They actually provide a number
of different operations within those.
And I typically don't like using access control lists,
because they are very coarsely grained.
If we were to use a policy,
I'm going to go ahead and cancel that,
because if we were to use a policy,
then the bucket policy allows us to be
much more granular,
and we can specify exactly which permissions
we want people to have.
And so going back here to access control, for example,
the read gives, like I said,
the read bucket gives quite a few different permissions.
But maybe we only want them to have some, but not others.
And we can do that with bucket policies.
And so with a bucket policy,
it's very similar to policies
that we might apply to our users in groups.
It's written in the same kind of language.
So I'm gonna go ahead and paste one here,
one that I've already prepared,
and then we'll just talk through it.
And you can see that we have a policy
that includes a version and a statement.
The version is not our version.
This is the version of the policy language,
and so this is the date on which that
version of that policy language was last published,
back in 2012.
So again, when you see versions within policies,
whether it's an S3 bucket policy,
or a policy applied to a user,
that version is pulled from the AWS documentation.
And so then, of course,
statement is really a collection of statements,
and we really only need one right here.
So we have one statement here.
And that statement says that we are going to allow.
This is the most important part
of this whole thing right here.
The principal, meaning we're using an asterisk here,
we're allowing anyone and everyone,
including anonymous users,
people who are not authenticated against the AWS API.
So essentially the asterisk here means public.
And then we're allowing anyone and everyone
the ability to perform the S3 get object action,
which means to download from anywhere
in this particular bucket.
So another important part of this is the resource,
and so we have the name of the bucket here,
and then slash star means
all objects in the bucket.
And so we could grant access only to a limited prefix.
We could say well, you're allowed to download,
but only from, only objects with a common prefix.
Or if we remove that again,
then we're saying every object in the bucket.
And then, of course,
we could list other actions.
We could say get object version.
We could say list bucket.
There's a number of other actions that we could get
that we could grant access to.
If we wanted the public at large,
anyone and everyone, to upload,
then we could also add the put object.
Using put object would allow people to upload.
So we don't need to do that.
So again, by allowing an asterisk here for the principal,
we're allowing everyone to download objects from that bucket
and I'm going to save that.
And now at the console is warning me.
Amazon has done a really good job of highlighting
buckets that provide public permission.
And so keep in mind that it is
the customers' responsibility
to configure these policies appropriately.
It is then your responsibility
to communicate with members of your team.
Hey, this particular bucket is public.
Don't put sensitive information there.
Now, it says this bucket has public access.
We highly recommend that you never grant
any kind of public access to your S3 bucket,
but I think that's a little heavy-handed,
because there are times when you need to do that.
If we were to go back,
we looked at this bucket earlier,
and then of course, while up here it shows
that this is public as well,
it's highlighting the fact that it's public.
But if we were to take a look at cerulean dot systems,
we looked at this earlier,
the reason it needs to be public
is because if we go to properties,
this bucket is configured for static website hosting.
If it weren't publicly readable,
then we would not be able to serve
the website from the bucket.
So I don't know if I necessarily agree with that statement,
never make them public.
There are times and places when you need to do that.
My recommendation would be,
be aware of what it means,
and communicate to your team
that information in that bucket
is now publicly available.
So again, just as a recap there,
if you wanted to, if you had a need,
to make certain buckets publicly available,
you could do that through access control lists,
or through bucket policies.