This course covers the core learning objective to meet the requirements of the 'Designing secure solutions in AWS - Level 2' skill
- Analyze the available options to secure credentials using features of AWS Identity and Access Management (IAM)
- Evaluate the appropriate routing mechanism to securely access AWS service endpoints or internet-based resources from an Amazon VPC
- Evaluate the appropriate encryption options available for data in transit and when at rest across AWS services
- Evaluate the most appropriate key management service and options based on business requirements and governance controls
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.