Implementing assume role

Assume role is one of AWS’s best practices, why?

1. While in an organization which have multiple AWS accounts, assume role could be used as a single sign-on. It is very inconvenient as well as very hard to manage multiple users from multiple AWS account. Assume role is preferred in these scenarios.
2. Assume roles more secure than IAM users.

An IAM user has permanent long-term credentials and is used to directly interact with AWS services. This means that unless you have configured otherwise, that IAM User credential does not expire. An IAM User credential consists of a Key ID and Secret Access Key (an AWS-generated pre-shared secret) that are good until you delete them. It also means that they do not have to be used from within your AWS account, or from any other AWS account. That Key ID and Secret can be used by anyone and anywhere.

Assume roles on the other hand expires after 12 hours(maximum), so you don’t have to worry about your keys lying somewhere or being misused.

3. Convenient to create a role than creating an user itself.

When in a scenario where a user or a service outside of the organization is required to access resources, it is very inconvenient as well as inappropriate to create an IAM user for that particular case only. Instead, we can create an assume role with permissions just for exactly the requirement.

For whatever reasons, if an user or an application has to access AWS resources belonging to another account, they need to assume a role that would allow them to access resources on another account.

Assuming a role can occur via the AWS Management Console, or programmatically via PowerShell, the AWS CLI, or the SDK’s for various programming languages. The permission “sts:AssumeRole” may be allowed for Users, Roles, Services, and a few other principal types.

Implementing assume role might be quite tempting and confusing. But once you have the idea inside your head, its actually very straight forward.

Overview

We have two accounts, say account-A(Prod Account) with AWS resources and account-B(Dev Account) with IAM users and groups.To configuring assume role for the user from account-B to resources in Account-A, following steps should be followed. Please note that while assuming role, you give up your current credentials temporarily.

Configuration in account A

1. Create a assume-role with associated policies.

1.1 While creating role, select the trusted entity as another AWS account. and provide account ID of account where IAM users or any other applications lie. External ID is preferred when a third party assume this role. In our case, IAM users are only using using this assume role, so is not required. If you want additional security enable Require MFA, but for the sake of simplicity, we are skipping this as well.

2. Attach the policies. We are using AWS managed Amazons3FullAccess. Click on next.

3. Add appropriate tags such as group that assumes this role or account name and click on next.

4. Give appropriate role name.. Note that the trusted entities is the account number the user of which would assume this role.

Copy arn of assumerole just created in a clipboard somewhere.

Configurations on Account B

1. Login to IAM console.
2. Setup IAM users and groups. It is always a good practice to create groups and attach permissions to group rather than assigning permissions on individual users. We have setup a group grp_s3_admin and are assigning permissions for the users on this group to assume assumerole-s3-access role.
3. Click on grp_s3_admin and click on inline policies. Create a custom policy as following and give an appropriate name. Click on Apply policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "< arn of the role to be assumed >"
    }
  ]
}

The difference between inline policies and IAM policies is that inline policies doesn’t appear anywhere else. It is in fact not desired to display this elsewhere.

4. Now, from the drop-down, click on switch role:

On the following window, enter account id/alias and assume role name and enter. You can now access the services to which related permissions are attached on the role.

Post scenarios

After assume role has been created, if additional permissions are required to the user, for instance in addition to s3 full access, the user needs to access Athena as well,

i. Add athena permissions on assumerole-s3-access in account B and the user will be able to use same assume role to access athena as well .

ii. Or you can create another assume role as assumerole-athena-access in account B and add assume role permissions in group grp_s3_admin in account A as:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [ 
                  "< arn of the assumerole-s3-access>",
                  "< arn of the assumerole-athena-access>"
                  ]
      }
   ]
}

The token are valid for a session which is 30 minutes by default. Another token is generated automatically after the session expires.

Assuming role via AWS CLI

After assume role has been set, there are few more steps to be followed for using those resources from AWS CLI. I’m assuming here you have already installed AWS CLI and are quite familiar with it. I’m demonstrating the changes in configurations when accessing resources from different account.

1. Open a command line tool.
2. Configure AWS: aws configure — profile STS and enter your access key and secret keys.
3. Edit ~/.aws/config file as:

[Profile STS] 
region = <aws-region>
output = json 
[default] 
role_arn = arn:aws:iam::123456789012:role/assumerole-s3-access source_profile = STS

Try:

aws s3 ls — profile STS

and it should then list the s3 buckets from account-A.