- [Alana] You've already learned how to assume a role using the AWS Command Line Interface. You simply run the STS assume role API call and you get temporary credentials back. However, you can also assume a role using the AWS Management Console as well. But before you can assume a role, you first have to create a role, which is what I'll be doing in this video. Let's say I'm an Identity and Access Management administrator for a large hotel chain. Part of my job is to provide the appropriate permissions to the staff that will be working with AWS. In particular, I have a group of developers that are creating a new feature for the hotel's website and they need access to Amazon S3. The first thing I want to do is double check that the developers don't already have access to Amazon S3. To do this, I access the IAM Management Console, which I'm already in, and find the developer group. To do this, I click on Groups, then the Developer group, and then make sure you're on the Permissions tab. Here, you can see all of the policies attached to your group. in this case, there is only one policy. If I view this policy, I can see that the users in this group have full access to Amazon EC2 and other related services. And that's it. If I wanted to, I could modify this policy and add in Amazon S3 permissions and be done. However, I know that there is another group in my organization that also has this policy attached to it and that group doesn't need Amazon S3 permissions. I don't want to give people permissions that they don't need, so I'll need to find another way. I could also attach another policy to this group that enables access to Amazon S3, but the hotel stores some really important customer data in S3 and I want to create another layer of protection to access that information. So to create layers of security and also follow the principle of least privilege, I'm going to create a role specifically for Amazon S3 and allow the users in this group to assume it. First step, I click on Roles in the sidebar and then click Create role. The first page is asking me to choose a trusted entity, which basically just means who is going to be assuming this role. I have four trusted entity options to choose from here. I can choose to create a role that will be assumed by an AWS service so that they can perform actions on my behalf, or I can choose to create a role for a user in my account or a user in a different account, and then finally there are two different federation options as well. For this particular demo, I'll be creating a role for users in this account to access resources. So I'll go ahead and click on another AWS account and then paste in my account ID. Also, if I wanted that extra layer of security to access Amazon S3, I could require multifactor authentication to assume the role by clicking this checkbox. But since it's just a demo, I will uncheck this and then click next. The next thing I need to do is select which policy I want the role to have. I know that I need to give my developers access to Amazon S3 and luckily there's a policy that already exists that allows full access to S3. To find it, I will type in s3full and then I will check this box next to the policy name. After I'm done, I'll go ahead and click next. Here, I can add tags to help organize my resources. A helpful tag might be the particular project that this policy was created for. So I could put in project as the key and the value could be s3-photo-website-feature. I could also put in Owner as a key and then have the IAM-admins as the value. So now I know why this policy was created, to provide permissions for this particular new feature, and I also know who owns this role. So if something goes wrong, I'll know who to contact. Now that I'm done with tagging, I can go ahead and click next. This is the review screen, but this is also where you select a name and description for your role. When choosing a name, you'll want to choose a unique name that is descriptive and make sure you get it right the first time because you can't edit the name after you create the role. AWS doesn't allow you to do this because other AWS resources might reference the role. And if that name changes, it becomes organizationally challenging, because you then have to chase down all references and change those too. In general, we like to avoid that. So for my role, I'm going to choose a unique and descriptive name such as DevAccessToS3. For your description, this is up to you. I generally like to say what the role is meant to do. In this case, it enables S3 access for the developer team to create the S3 photo website feature. After that, I will quickly review, make sure it looks good and then click create role. And now I have successfully created a role. In the next video, I'll show you how to actually use this role so that the developers can actually begin to access Amazon S3. I'll see you next time.
