Using IAM User Roles to Grant Temporary Access for Users
Start course
4h 50m

This section of the AWS Certified Solutions Architect - Professional learning path introduces the key identity management, security, and encryption services within AWS relevant to the AWS Certified Solutions Architect - Professional exam. Core to security is AWS Identity & Access Management commonly referred to as IAM. This service manages identities and their permissions that can access your AWS resources, so understanding how this service works and what you can do with it will help you to maintain a secure AWS environment. IAM is an important service in ensuring your resources are secure.

Want more? Try a Lab Playground or do a Lab Challenge

Learning Objectives

  • Learn about identity and access management on AWS, including users, groups & roles, IAM policies, MFA, identity federation, and cross-account access
  • Learn the fundamentals of AWS Web Application Firewall (WAF), including what it is, when to use it, how it works, and why use it
  • Understand how to configure and monitor AWS WAF
  • Learn about AWS Firewall Manager and its components
  • Learn how to configure AWS Shield
  • Learn the fundamentals of AWS Cognito

There might be circumstances where you will need to grant temporary access to AWS resources for a particular user and the best way to do this would be to allow the user to assume a role with these new permissions. The alternative would be to either add a policy associated with the user and then remember to remove the policy again afterwards, which would likely lead to a security risk, and as we know, attaching policies to a specific user isn't considered a security best practice, we should use user groups instead. However, if we added these permissions to a user group that the user belonged to, then all users that are a part of that same user group would receive those permissions, so that's definitely a security risk.

So in this instance, creating a new role with the relevant permissions and allowing only specific users to assume that role, is the best approach to the problem. When a user assumes a role, it replaces all other permissions that the user has. You might think that the user keeps their current permissions and just inherits the additional permissions set out by the role, but that's not the case. When you assume a role, your existing permissions are temporarily replaced.

I mentioned previously that every role has a trust relationship and so as a user, you can only assume roles where they have been added as a trusted entity. However, in addition to being trusted, the user also has to have the relevant permissions to assume the role as well and this is done via an access policy.

So let's assume we have a role called RoleS3FullAccess with a permission policy attached as shown which grants full access to Amazon S3. And the trusted entity of this role was defined as the user specified in this ARN. So this means this role trusts the user, Stuart, to assume the role to gain full access to S3. However, Stuart's permissions do not currently allow him to assume this role. For Stuart to be able to assume the RoleS3FullAcess role, Stuart will need to have the following policy associated with his user, where the text in red is the ARN of the role. When this policy is associated with Stuart, he then has permission to assume the role which is trusted to him as defined in the trusted entity section of the role allowing him to have full access to S3.

Let me now provide a demonstration on how you could create this example that we just ran through. Okay, so I'm in my AWS Management Console and I'm at the IAM dashboard. So in this demonstration, we're going to create a role with a policy attached and then add an inline policy to the user, Stuart, to ensure that Stuart can assume the role.

So firstly, let's create our role. So on the left here, we have roles and then over in the top right, we have Create Role. So because we want this role to assumed by a user, we have to pick the correct type of trusted entity. So it's not going to be assumed by an AWS Service and it's not to with Federation either, so the option we need here, is this one relating to an AWS account. Now although says another AWS account, this option is used to creating cross-account access, but you can also create roles to be assumed by users within your own account as well. And to do that, all we need to do in the account ID, is to enter our our account ID, so if I just add that in there, and you can also add a couple of additional options, such as requiring multifactor authentication, et cetera.

So once we've put in the account ID of where the users are that we want to assume this role, we can then click on next, permissions. And I want the policy that's attached to this role to have full S3 access, so let's have a quick search. And here we have it here, Amazon S3 full access, which is an AWS managed policy. Then click on next for tags. Add any tags in that you'd like for the role as an optional step. I'm just gonna leave it blank for this demonstration. And this is where we can give the role a name, so I'm going to call this RoleS3FullAccess. Give it a description if you need to and here we have the trusted entity, which is my own account and then all we need to do from there, is click on Create Role.

Okay, so if we search for that. RoleS3, here we have our role here. So if we go into the role, we can have a look at our trust relationships, so this is essentially saying that anyone within this account is trusted to assume this role and we can also edit this trust relationship as well. So this shows the policy that relates to that trust relationship. So this essentially allows anyone in this account, access to the role, as long as they have that assume role permissions that we'll be looking at in just a moment. But I want to make this a bit more secure, so I'm going to change it from root to user, Stuart.

So now the trusted relationship for this role will only allow the user, Stuart, within this account to assume the role, given the correct permissions. So I'm gonna update that trust policy and now we can see the trusted entity has been changed. And if we take a look at the permissions, we can see that it has the policy attached there as well. So now we've got roles set up with the correct permissions, we now need to edit the user, Stuart with an inline policy to allow that user to assume the role. So I've just gone with IAM user of Stuart. If we click on add inline policy and go across to JSON.

Now, here I'm just going to paste in a policy that I've already created. So will allow the user, Stuart to use the secure token service AssumeRole action against the role that we just created and that's the ARN in the role. So now Stuart will have access to assume that role. Let's go to review policy. Give this a name. I'm just going to call this, AssumeRoleS3. Create policy. And there we have the inline policy that we just created, attached to the user, Stuart.

So now what I want to do, is to log in as the user, Stuart and show you how I can switch to this role. Okay, so I've now signed in as the user, Stuart and to switch roles, all I need to do, is to select on the top right up there, select Switch Role. And again, Switch Role. Type in the account. So I'll just paste that in quickly and then type the role name, which we called RoleS3FullAccess and then click on Switch Role. And that's it, we've now switched roles and if you look in the top right, we can see that it says, RoleS3FullAccess at this account number and that signifies that you swapped your permissions for that role that the user, Stuart has just assumed.

Once you finish what you need to do with the permissions given by the role, you can simply select the top right area again and say Switch Back. And that will revert you back to your original user with your original permissions. IAM user roles are often used to create a cross-account access role, allowing users in one AWS account to access resources in a different AWS account. For a full explanation on how to create cross-account roles, please see our existing course found here.

About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.