- Now let's review bucket security with resource policies.
We've talked about this before, resource based policies.
They are essentially the same as policies that
we would apply to our IAM users and groups.
But they are applied at the resource level.
In this particular example, what we're gonna
look at is the policy that's applied
to the Amazon simple Storage Service Bucket.
We could also apply resource based policies to other
services like Simple Queue Service, DynamoDB and others.
One of the key differences that sets resource policies
apart, aside from being applied at the resource level,
is that we will specify what we call a principal.
And that is who is allowed to perform these particular
actions or who is being denied these particular actions.
But we could allow another account.
So we could leverage that to give
cross account resource sharing.
We could point the principal to a particular IAM user or
group or role, we could give
permissions to another Amazon service.
Or as we're going to see in this following example,
we could give permissions to anonymous users.
Anyone outside of Amazon, anyone in the world.
So now let's take a look at an example.
Here's an example policy that we would apply
directly to an S3 Bucket, so one of the first
things that we need is the version.
It's not symantic versioning, it's a date based
versioning that and we can find this particular
value in the Amazon documentation.
So here, again, we need to specify whether
we are allowing or denying, in this case we're
going to allow anyone, that is anyone in the world,
regardless of whether they have an Amazon account or not,
to essentially download using the S3 get object action,
any object in this particular bucket.
You'll notice that the slash star means
any object in the bucket, and we could have other
types of permissions that would apply to the bucket itself.
And so here's another example of a policy we might
apply to a bucket that would grant cross account access.
So, what we're doing here, if you'll notice, instead of
specifying a star or a wildcard for the principal.
Which would in the previous example, granted
access to anyone and everyone, all over the world,
regardless of whether or not you had an account.
This one here was saying the principal is going
to be some member of AWS, in this case,
we're pointed to an Amazon resource name,
that includes the account number of some other
account that we want to share access with this bucket.
And notice here, so that's gonna be the account number.
And then root is essentially, we're saying that
that entire account, or the root user of that account
is allowed these kinds of permissions.
And from there, that root user can then
delegate these permissions to other members of
that organization, to other IAM users.
Now this could be an account that we own,
another one of our accounts like development versus
production environment accounts.
It could be a customer's account or
a vendor's account, some third party.
It doesn't really matter, the point is is that
by specifying the principal as an IAM arn using the account
number and root is how we share a bucket across accounts.
In this example, we are going to give that other
account the ability to list the objects within the bucket.
And so here that particular action would actually
apply to this resource, the bucket resource.
And then the put object and get object actions
would apply really to the objects within the bucket.
So you'll see here that this is an important distinction
between these two resources in the case of S3, being able to
separate the bucket from objects in the bucket.
And it's just a very minor difference in syntax
between the slash star there at the last one.
So that is Resource Based Policies being applied
to an S3 bucket in Amazon Web Services.