- So here let's discuss permissions and policies
within the AWS Identity and Access Management Service.
So we've talked about how we allow our users to authenticate
and authorize against the AWS API.
It's one thing to have a user account,
but that user account by default does
not allow your user to do anything.
In order for our users to be able to actually do their job
and create resources within Amazon Web Services,
we need to grant them permissions.
We have to have an explicit allow
somewhere within their account in order
for them to be able to do anything,
and we do that by way of policies.
Policies are just a simple JSON text.
JSON being JavaScript Object Notation
that we'll talk about later on.
Now we have two different types of policies.
We have what we call manage policies,
which are top level first class objects that can be
directly created and managed apart from other resources.
And you can see that we have both an AWS managed,
meaning that these are policies that are created
and managed by Amazon Web Services,
and then we have customer managed policies.
These are policies that we create and manage on our own.
And so it's common for customers to have their own library
of policies to apply to different
types of users or different groups of users.
And then of course we can have the other type of policy
would be what we call an inline policy.
The inline policy would be where you would put
that policy directly onto a user's account
rather than referencing a managed policy.
Now we have a couple of ways that we can create policies.
We can either use a generator,
which is a simple UI tool that Amazon Web Services gives us
that allows us to choose the service type of actions,
and it will write the JSON policy for us.
We could also just handwrite it
if we want to as well or copy and paste.
Now it's important to understand
the evaluation logic of policies.
They all start with a default implicit deny,
so again, you can't do anything
unless you have an explicit allow.
So the policy evaluation logic
first starts with that implicit deny.
Then it actually looks for an explicit deny.
That's important because generally
you use the explicit denies, and we'll talk about this more
later on, but you would use an explicit deny
to create perhaps what you could
call some safety rails around things.
So with an explicit deny, it can never be overridden.
If you say that a user is not allowed to do something,
then no matter where else they might be allowed,
the explicit deny will always win.
That's the great security layer
that we have access to within policies.
And then of course if it doesn't find an explicit deny,
it will then look for an explicit allow.
So remember that they start with an implicit deny,
and they look for that explicit deny,
which overrides everything, and then,
in order for a user to be able to do anything,
they have to have somewhere an explicit allow.
So before we look at an example policy,
I wanna talk about one other thing
that's really important to understand.
This is very, very key thing in order to understand
security in Amazon, in order to understand writing policies,
and it's called the Amazon Resource Name,
and Amazon Resource Name is a way of uniquely identifying
a particular resource across all of Amazon.
When you imagine that Amazon web services has
over one million paying customers across 14 regions,
38 availability zones, across the entire globe,
there are lots and lots and lots of resources.
Some customers, just one customer may be running
thousands of virtual machines.
They may have dozens of databases, so one customer
might have millions and millions, perhaps even billions
of objects stored within Amazon simple storage service.
It's important to be able to uniquely identify
every single resource within all of Amazon web services,
and we can do that with an Amazon Resource Name.
So you'll notice here that the Amazon Resource Name
follows a particular pattern.
They all start with arn:.
These different parts of the ARN are separated by colons.
So you can see that it will be arn:partition,
the partition being the
high level organization of Amazon Web Services.
Most of the partitions will be named AWS.
If you're operating out of the China region,
one other example is the partition
in that particular case might be AWS-CN,
but for the most part, they will all be AWS.
And then of course comes the name of the service,
the region that we're operating in, such as US West Two
or US East One, the account ID, the resource type,
what kind of resource we're dealing with,
whether it's an s3 bucket, an EC2 virtual machine, or so on,
and then of course the actual name of the resource.
Some resources are separated by a slash.
Sometimes it's a colon.
It's always best to just to go back to the documentation.
I've been using Amazon Web Services for seven years now,
and I constantly go back to the documentation.
These details are too much to remember.
So make the documentation your best friend in these cases.
So just a couple of examples of ARNs.
If we wanted to uniquely identify one user
out of the millions of users that
exist within Amazon web services, this might be our ARN.
You'll see here that it follows that pattern.
Arn:aws: the name of the service, iam being
the service here, and you'll notice
that the region is left blank.
You'll see here that for global services like iam,
the region is not necessary because
it doesn't matter what region.
And then of course we have the account ID,
and as we'll talk about later,
it's very possible and it's very common
and in fact it's suggested, recommended, best practice
to leverage multiple accounts for your environment,
and we'll talk about that later,
but here we have the account ID.
And then of course what we're saying,
the resource type in this case is a user,
not a group, not a role, not anything else but a user.
And then of course the name of that
user in this example being bsmith.
Another example of an ARN is in the case of
here the example is for Amazon Simple
Storage Service, otherwise known as s3.
It's arn:aws:s3, and you can see here in this example,
that the region and the account number are both left blank,
and that's because the name of the bucket
is itself globally unique, and because of that,
we don't need the region or the account ID.
And the last example, all of them are filled in,
the name of the service, the region, the account ID.
In this particular case we are talking about
the Amazon relational database service,
and we are targeting a very specific database
within a particular account within a particular region.
So again, these are the Amazon Resource Names
and a very important thing to understand
when we get into writing policies.
So let's take a look at this example policy.
Now again, as we have talked about,
policies are written in JSON, JavaScript Object Notation.
It's just a simple collection of t value pairs.
Here one of the first things that we need
within our policy is the version,
and we have our key over here called version.
It's quoted, and then the value
separated by a colon, also quoted.
Now the version in this case is not
a semantic version like 1.1 or 2.4.
It's the date at which this policy was last published,
and we can find those versions within the AWS documentation.
The next thing that we need in our policy is a collection
of statements, and you can see that
the square bracket denotes a list or an array.
In this case, we only have one, but it's still a collection.
Now here what we're saying is that we're allowing
this user to perform these two actions.
We can see that actions are prefixed
by the name of the service, in this case,
Amazon Simple Storage Service or s3
is prefixed here to these two actions.
So it's like a name space for those particular actions,
and we're saying that we're going to allow this user
or group of users to download and upload
to this particular resource, and in this example,
as we've talked about, this resource using an ARN,
we're specifying that they're allowed to perform
these actions anywhere within the bucket,
so you'll notice that the bucket would be
mybucket, but the /* is yet another thing.
The /* indicates everything within the bucket.
So again the bucket is one resource.
Objects within the bucket are another.
We'll talk more about how the simple
storage service works later on.
So as we've talked about,
the evaluation logic, it starts with the implicit deny.
It will first look for an explicit deny
and then look for an explicit allow.
So it's also important to note that
users or groups of users can have multiple policies,
and each policy can have multiple statements,
so it would be possible that a user or group of users
somewhere within their policies has a deny
that would override this allow.
It doesn't matter in what order.
The evaluation would first look for a deny,
and then only if it didn't find one
would this allow actually take effect.
So again, this is an example, just one example of a policy
within AWS Identity and Access Management Service.
So ultimately what we can see based on that last example
that policies are essentially
just collections of statements.
It is possible for a user or group of users
to have multiple policies attached.
The statements simply specify, in the case of resource
space policies as we'll talk about more later on,
we specify the who, otherwise the who is already
implicit depending on who the policy is attached to.
We specify actions, the things
that that user is allowed to do.
We specify resources, the actual Amazon Web Services
resources that our users are allowed to do things with.
And then of course, we also have
the ability to specify conditions.
Just a few examples of the possibilities
would be perhaps we want to limit the time of day.
Perhaps we would want to say these users are allowed
to do certain things only during working hours.
Perhaps we want to limit them from a specific IP address,
such as our corporate static IP.
Perhaps we want to say that a group of users
is only allowed to do something, if that resource,
such as a virtual machine or a database,
is tagged in a particular way.
So with permissions via policies
we have very, very fine grain control
over who can do what to what resources
throughout our Amazon Web Services environment.