- Now let's take a look at bucket security with
resource policies and ACLs.
Many resources in AWS support, what we would call,
resource based policies.
Earlier in this series, we talked about
policies within IAM.
Policies that grant permissions to access,
perform certain actions on certain resources.
Policies like that, in many cases, can and should
be applied to users and groups but in other cases
we may want to apply or need to apply the policy
directly to the resource.
Here is an example where we are applying a policy
directly to an S3 bucket.
And the reason that we're applying the policy to the bucket,
in this particular case, is because if we notice here.
If we take a look at the principle.
The principle you'll see is,
in this particular case, an asterisk.
And the asterisk, in this case,
means that we are allowing anyone and everyone,
even people who don't have an account with AWS.
Even anonymous users.
People who are not authenticated.
So, by placing an asterisk here,
we are essentially enabling this bucket
to be read by the public.
Anonymous users.
What we're saying here is that, essentially
asterisks, anyone and everyone is allowed to download
using the S3 GetObject action from anywhere
in this particular bucket.
This bucket being cerulean.systems.
In this particular case, if you were to visit that domain,
cerulean.systems then you would see a website
and it would be static content.
A static website being served directly
from that particular bucket.
We can do a number of different things
with resource policies.
Resource policies will also allow us
to share buckets between different accounts.
In this example, you'll notice that
we are specifying again the principle.
But we are saying, using the AWS key here,
we're saying that we want to share this account
or at least allow these particular actions
with this particular account.
So we're specifying this particular account number.
This particular action, the S3 PutObject action,
is then essentially delegated to that account.
To the root of that account.
The root user of that account can then
further delegate that permission to their users.
Essentially, what we're saying here is this
some other account is allowed to upload,
perform the S3 PutObject action to anywhere
in this particular bucket.
Resource based policies allow us to do several key things.
One, either generally making them publicly accessible
or sharing them with another account.
S3 is one example of resource based policy usage.
Simple Queue Service and other resources also
support resource based policies.
Another thing that we can do with S3,
in terms of making a bucket or objects publicly readable
or sharing or granting access,
is either using a policy like we just saw.
We can use a policy where if we specify an asterisk
for the principle then we are sharing that
or granting access to anyone and everyone.
Another way that we can grant access
is by using ACLs or access control list.
A resource based policy, a bucket policy
allows us to be very, very fine-grained
and specify conditions and all kinds of things
to really target the different actions
and different resources under different conditions.
But ACLs are more core-screened.
So, if we were to specify read operations
or write operations, those would actually end up
including a number of different actions
that we might specify in a policy.
Personally, I prefer to use policies
because they are fine-grained
and I only generally use ACLs
in very certain circumstances
when that's the only option.
In terms of making data publicly readable.
I want to spend some time here because over the last
few years, a number of organizations have gotten themselves
in trouble by exposing sensitive information in
publicly available S3 buckets.
I think, mainly, that comes down to a lack of education
and/or a lack of communication.
That perhaps the person who created or put that policy
or ACL into place didn't realize what they were doing
or they did but didn't communicate that was a
publicly accessible bucket to people who were writing data.
As an organization, we need to keep in mind that the
security of our data within these S3 buckets
is our responsibility.
The onus of knowing, the consequences of using
these kinds of things, is on us.
We have to be aware of these kinds of things
and we have to educate ourselves, educate our team
and communicate that this particular bucket
is publicly accessible and it should only be made that way
if it needs to be that way.
There are several canned ACLs that we can use to make
certain objects or buckets publicly readable.
One of them, as the name suggests, public-read.
That one's very straight forward.
If you apply that ACL to an object or a bucket
it will be accessible by the public.
Another one would be public-read-write.
Meaning that now it's not only readable by the public
but it's also writable.
That people can write to it.
Anonymous users can write to that.
Another one that is perhaps, anti-intuitive,
counter-intuitive, is the authenticated-read.
I want to draw your attention to this one
and make sure that you remember this.
If you take away anything, take away this.
The authenticated-read ACL
applies to anyone who authenticates to the AWS API.
Even those users outside of your organization.
Keep in mind that anyone in the world
with a valid credit card can sign up
for an AWS account.
Even people with potentially malicious intent.
Some random person out there
could sign up for an AWS account
and if your data has the ACL authenticated-read
this person could access it.
This is really one that I would recommend avoiding.
I'm really not sure exactly why that's in there
but I would recommend avoiding that.
There are plenty of other ways to
grant access to your users rather than using
the authenticated-read canned ACL.
Those are some things to keep in mind
as you move forward and continue to work with S3.
Keep in mind that the security of that bucket
is your responsibility and you can leverage
these kinds of things; bucket-based policies and ACLs
to help manage the permissions of that bucket.
When it comes to allowing access to that bucket
from the public or from other accounts.