- [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.
