- [Morgan] In a previous lesson, you learned about IAM

users, groups, and policies. Policies can be applied to AWS identities like users
and groups
to assign permissions. They also, however, can be
applied to another AWS identity, IAM Roles. An IAM role is an identity that can be
assumed by
someone or something who needs temporary
access to AWS credentials. Let's dive into what exactly I mean when I say AWS
credentials. Most AWS API calls that are made must be signed and authenticated, but
how does that process work? Well, from a high level, when you send an HTTP request
to AWS, you must sign the request. This signing process allows
AWS to verify your identity when a request is made and it's run through
various security processes to ensure that a request is legit. IAM users have
associated credentials like an access key ID
and secret access key that are used to sign requests. However, with regards to our
architecture, the code running on the EC2 instance needs to sign the request sent
to S3 for the employee photos. I already told you that
I do not intend for you to create an IAM user with credentials to be used by this
app. I also do not intend for
you to hard-code credentials into this app at any point in time. So, how will the
application gain access to the needed AWS access key
ID and AWS secret access key to sign the API calls? The answer? IAM roles. IAM
roles are identities in
AWS that, like an IAM user, also have associated AWS
credentials used to sign requests. However, IAM users have
usernames and passwords as well as static credentials like the access key and
secret access key, whereas IAM roles do not
have any login credentials like a username and password, and the credentials used
to sign requests are programmatically
acquired, temporary in nature, and they are automatically rotated. In our example,
the EC2 instance will
be assigned an IAM role whenever you launch it. This role can then be assumed by
the application running
on the virtual machine to gain access to the
temporary credentials needed to sign the AWS API calls being made. A role can be
assumed by
many different identities and they have many use cases. The important thing to know
about roles is that the credentials
that they provide expire and roles are assumed programmatically. To get an idea of
this, let's
go ahead and create a role using the AWS Management Console. I'm already logged in
to my AWS account and now what I'm going to do
is navigate to the IAM service by just typing IAM in the
toolbar here and selecting this. And now what I want to
do is create the role that our EC2 instance is going to use for the employee
directory application. So to do that, I'm going to click on roles
over here in the left-hand side and then I'm going to click create role. From here,
you have to select
what trusted entity is allowed to assume the role,
because again remember, these roles are being
assumed programmatically. So we are going to go ahead and select EC2 as the trusted
entity to assume this role and then we will click next. And now we can attach
permissions to this role. On this screen, you can look through the
AWS managed policies, which are policies that are
created and maintained by AWS, or you can create your own policy where you can get
really
specific and granular with the types of permissions that you want to give to this
role. For this specific example, I need this application to
be able to read and write to Amazon S3 and we're also going to need
to give this application access to Amazon DynamoDB, which is a database. So what
I'm going to do is I'm going to use the
AWS Managed Policies here. So I'm going to type in S3 and then I'm going to select
the AmazonS3FullAccess role. And if we open this up, you can see what the policy
looks like. This policy here has one statement where we are allowing the action of
S3:*. So that is all S3 actions
against all S3 resources. So this is a very broadly
scoped permission. For our simple proof of concept,
we are going to use this. In real life, you probably
want to create custom policies that really narrow down the
scope of those permissions, but I'm going to go ahead
and select S3FullAccess and then I'm also going
to look up DynamoDB and we will select
AmazonDynamoDBFullAccess. Next, we will click tags. And from here, we can add tags.
Tags are just user-defined key value pairs that are associated with a resource.
These can come in handy for
billing and resource management and all sorts of things. So we're going to go
ahead and give this a name and this will just be
employee-directory-app. That's the value of our tag. Next, we'll click review. And
now we will give this role a name, the name being EC2S3DynamoDBFullAccess. And now
we can click create role and we can see that that
role has now been created. The role that we just
created is going to be used in future lessons and demos when we build out our
employee
directory application. It's very common for roles
to be used for access between different AWS services. Just because two resources
exist in the same AWS account, it doesn't mean that they can
send API calls to each other. If one AWS service needs
to send an API call to another AWS service, it will most likely use role-based
access where the AWS service assumes a role, gains access to the temporary
credentials, and then sends the API call
to the other AWS service who then verifies the request. Another identity that
can assume an IAM role to gain access to AWS is
external identity providers. For example, let's say you have a business that
employs 5,000 technical employees and they all need access
to an AWS account. You already have an
identity provider in place that allows these employees
to log into their laptops and access various corporate resources. Should you also
now go
create 5,000 IAM users for these employees to access AWS? Well, you can, but that
doesn't sound very efficient. You can leverage IAM roles to grant access to
existing identities from
your enterprise user directory. These are known as federated users. AWS assigns a
role to a federated user when access is requested
through an identity provider. We also have AWS services that can make this process
a little bit easier, such as AWS Single Sign-On. These are a couple of examples
of role-based access in AWS. And this is just the introduction. Check out the class
readings
for more information. And don't worry if you don't
quite grasp this concept yet as we will use roles in our demos throughout this
entire course. And you will also gain experience using IAM roles in your own
account through our hands-on exercises.