- [Morgan] Let's take a

look at the application we are going to be building

throughout this course. We've already gone over the
design of this application, and what I want to do is focus
now on the access control. There are multiple places on this diagram where we can
identify the need for access control and
credential management. The first being that we need to manage how users log in and
use the
employee directory application. We could require that people
have a valid credential, like a username and password
to log into the app. That is access management
on the application level. Then there's the fact that we know the code running the
employee
directory application is running on a virtual machine, being hosted by the service,
Amazon EC2. That code will need to make API calls to the object storage service,
Amazon S3, in order to read and write data like the images for the employees. Well,
here's the thing,
just because both Amazon EC2 and Amazon S3 have existing
resources in an account it doesn't mean that the API calls made from the code
running
on the EC2 instance to S3 are going to be automatically
allowed to be made. In fact, all API calls in
AWS must be both signed and authenticated in order to be allowed - no matter if the
resources live
in the same account or not. The application code running on Amazon EC2 needs access
to credentials to make the signed API call to Amazon S3. So that's another place
with a need for credential
and access management. Now let's take this a step further. How are you going to
build
out this architecture? Well, you'll need access to an AWS account through the use
of a login. Your identity within this AWS account will need permissions
to be able to do things like create this network,
launch EC2 instances and create the resources that host and run this solution in
AWS. Yet another place you need credentials. The root user, which you
have already learned about in a previous lesson,
has these permissions but you don't want to
be using the root user to administer your AWS resources. And also let's assume that
you won't be the only one working on building out this application. It's more
likely that
within one AWS account there will be many people who need access to build and
support your solutions. You'll have different groups of people responsible for
different
parts of the architecture. The people who would
write and deploy the code might be software developers, whereas the people who
would be responsible for making changes to say the network would be a totally
different group of people. You wouldn't and shouldn't
give everyone who needs access to the AWS account the root
user credentials to log in. You instead would have unique credentials for each
person logging in. This is where the service, AWS Identity and Access
Management comes in. We identify three places
that we will need access and credential management
for the solution, AWS Identity and Access Management or what we call IAM can help
take care of these two spots on the diagram. AWS IAM manages the login credentials
and permissions to the AWS account itself and it also can manage credentials used
to sign API calls
made to AWS services. IAM would not however be responsible for the application
level access management. The code running on this instance would you separate
appropriate mechanisms for authenticating users into the application itself -- not
IAM. All right, so let's start
with the AWS account level. IAM allows you to create users and each individual
person who needs access to your AWS account would have
their own unique IAM user. Creating users for everyone
who needs access to the account takes care of the authentication piece,
authentication being verifying if someone is who they say they are because they
logged in with
the proper credentials. Now it's time to introduce authorization. Authorization is
this:
Let's say you've logged in and you are who you say you are. You've been
authenticated. Now you want to create
and manage AWS resources like create an Amazon EC2
instance, for example. So sure you've logged in but do you have the correct
permissions to be able to complete that action? The idea that your permissions
control what you can or cannot do is authorization. Are you authorized to
launch an EC2 instance? IAM users take care of the authentication and to take care
of authorization, you can attach an IAM policy to a user in order to grant or deny
permissions to take specific actions
within an AWS account. And keep in mind, when I say action here, I'm referring to
an AWS API call. Everything in AWS is an API call. IAM policies are JSON-based
documents. Let's take a look at an example. This IAM policy document
contains permissions that allow the identity
to which it's attached to perform any EC2-related action. The structure of an IAM
policy has an effect which is either allow or deny, and action, which is the AWS
API call. In this case, we have ec2:* which that would include all
of the EC2-related actions. You can restrict this to
be specific API calls. For example, I can restrict this action to be just run
instances. And then any user with
this policy attached would be able to run EC2 instances but perform no other EC2
related tasks. IAM let's you get very granular with your permissions in that way.
We see the resource, which allows you to
restrict which AWS resources the actions are allowed
to be performed against. You can also include
conditions in your policies that can further restrict actions. IAM policies can
also
be attached to groups. IAM groups are very simply
just groupings of IAM users. You can attach a policy to a specific user or to a
group. When you attach a policy to a group, any users that are a part of that group
would inherit the permissions. We recommend that as a best practice, you organize
users into groups and assign permissions to groups instead of individual
users where possible. This makes it easier to manage
when people change job roles, or maybe multiple users need permissions to be
applied or revoked. Another best practice to follow is that we recommend when
you create your AWS account you first set up MFA for the root user, then create an
IAM user with
administrator permissions, log out of the root user and then log in with the new
IAM user that you just created. From there, you can use this user to create the IAM
groups,
users and policies for the rest of the people
using this AWS account. The reason we suggest that you do this is because you can
not apply
a policy to the root user but you can to an IAM user. Now, I've told you about IAM
users, groups and policies. So we addressed this
part of access management that we needed for our application. But what about this
part? The EC2 instance needs credentials to be able to make these
signed API call to S3 for reading and writing employee images. Am I suggesting that
you make an IAM user with a username and password for the application running on
EC2 to use? No, no, I am not. This is where role-based
access comes into picture. Coming up next, we will learn about the temporary access
that IAM rules provide and how it can be
applied in this use case. Stay tuned.