Skip to content

thetrainit

  • Home
  • Articles
  • About

Category: Switching Roles

Posted on July 2, 2020

Switching Roles Using the CLI

In the Advanced Architecting on AWS course there is a slide on switching roles.

The process is as follows:

In this post, I will walk through the set up for CLI. In a previous post, went through the steps to configure the same using the console.

I assume you are familiar with the CLI, how to configure keys for CLI use, and the concept of roles.

The pre-requisites are as follows:

Create a second AWS account. I will refer to the two accounts as the Trusted Account and Trusting Account. The two accounts can be part of the same organisation, or not.

Install the AWS CLI on your local machine (or an EC2 instance if you don’t want to mess with your local machine. The AMZ Linux2 AMI has the AWS CLI already installed)

Create a user in the trusted account. Select the access-type Programmatic Access. I named the user “Admin” and attached the AWS managed policy “AdministratorAccess”. Save the credentials.

Use “aws configure” to configure the access-key and secret-access-key on the local machine.

Configure a role in the trusting account as follows:

In the IAM console, create a Role, and for the type of trusted entity, select “Another AWS account” and supply the account ID of the trusted account. I named the role “CrossAccountAdminRole” and attached the AWS managed “AdministratorAccess” policy.

The role ends up with a trust policy similar to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<trusting account id>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Perhaps not obvious, but this doesn’t mean that only the root user of the trusted account can assume the role. It means that any user in the trusted account with appropriate permissions can assume this role. Appropriate permissions means sts:assume role permission for this particular named role. In my case, I will be using a user with Administrator rights in the trusted account, so it will have permissions. In real life, the administrator can attach a policy to the trusted user which allows the user to assume the role similar to this:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<trusted account id>:role/CrossAccountAdminRole"
  }
}

 

To summarise the above, cross account roles requires two things:

  • The trusting account administrator creates a Role, and give the trusting account permissions to assume it.
  • The trusted account administrator gives users in the trusted account permission to assume the role.

Finally we get to the point of the post:

There are just two lines to configure as follows:

 

aws configure set profile.<profilename>.role_arn arn:aws:iam::<trusting account id>:role/CrossAccountAdminRole

aws configure set profile.<profilename>.source_profile default

Where <profilename> is anything you want

This configures the profile to allow the default profile (which for me is Admin in the trusted account) to assume the role CrossAccountAdminRole in the trusting account.

To test it you could create a resource in the trusting account, for example an S3 bucket and then type:

Aws s3 ls –profile <profilename>

The .aws/config file looks similar to this:

 [default]

region = eu-west-1

[profile testprofile]

role_arn = arn:aws:iam::123456789012:role/CrossAccountAdminRole

source_profile = default

By appending –profile <profilename> to the command, the CLI will use the profile, which is configured for an IAM role. The CLI will automatically make an STS:AssumeRole call and cache the returned temporary credentials. Subsequent calls made using the same profile will use the cached temporary credentials until they expire. When the credentials expire, the CLI will automatically repeat the process to acquire new credentials.

With this method, you keep your trusting account secure by using temporary credentials, and you manage IAM users by keeping your users in one account, the trusting account.

 

 

Posted on July 2, 2020July 2, 2020

Switching Roles Using the Console

This walkthrough uses a role to delegate access to resources that are in different AWS accounts. You share resources in one account with users in a different account. By setting up cross-account access in this way, you don’t need to create individual IAM users in each account. In addition, users don’t have to sign out of one account and sign into another in order to access resources in different AWS accounts.

This walkthough requires 2 accounts. They do not have to be in the same organisation, but can be.

In later posts, I expand on the scenario by using the same concept for CLI access, but using the console is a good place to start before looking at that.

I will call the accounts “the trusted account” and “the trusting account”. The trusting account contains the resources that the user in the trusted account will access.

In the trusted account we will create a role which can be assumed by a user in the trusting account.

To keep it simple, I will attach an administrator access policy to the role. In real life, you would use the principal of least privilege, for example, if the user only needs access to an S3 bucket, then the policy would only allow that.

It will be useful to use a text editor as a scratch pad so you can copy and paste the two account ids, and names of roles and policies that you create.

Account ids can be seen from “My Account” in the drop down menu below the logged in username in the top right of the console.

I assume you have an IAM user with full admin rights set up in each account.

In the trusting account:

Navigate to IAM,Roles, Create Role.

For “Select type of trusted entity”, select “Another AWS Account”

Supply the account ID of the trusted account,  and click Next.

For “Attach permission policies” select “AdministratorAccess”.

I named the role “CrossAccountRole”

The role now has two policies: the “AdministratorAccess” policy, and a Trust policy. To see the trust policy, select the role, click on the “Trust Relationships” tab, and click “Edit trust relationships”.  It will be similar to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<trusted account id>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

This policy allows a user in the trusted account to potentially assume the role. However, they still need permissions in order to assume the role. Any user with Administrator Access in the trusted account has such permissions. They would also be able to give other users permissions to assume the role. This is called delegation, which we will see how to do later.

In the trusted account:

In the top right of the console, below the logged in user name, select “Switch Role” from the drop down menu.

Supply the account id of the trusting account, the name of the role “CrossAccountRole”, choose a display name, and click “Switch Role”. You are now logged in to the trusting account with Administrator rights. From the same drop down menu in the top right, you can choose “Back to <username>” to switch back.

And that concludes the first part of the walkthrough.

In real life, you would use the principal of least privilege. The cross account role in the trusting account would allow only the required permissions, and the user in the trusted account does not need to be an admin in the trusted account.

To see how an ordinary, non admin user could be given permissions to assume the role:

In the trusted account:

Create a policy. For service, choose STS. For “Access Level”, choose Write, then tick AssumeRole. For resource, choose Specific.  You are given a friendly way to generate the ARN by supplying the trusted account id and the name of the role in the trusted account.

Click Review Policy and supply a name for the policy. I called it “AssumeCrossAccountRole”

The policy will look something like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<trusting account id>:role/CrossAccountRole"
        }
    ]
}

Create a user. I named the user “TrustedUser”. Allow Console Access, and click Next. Choose “Attach existing policies directly” and select the policy “AssumeCrossAccountRole” just created.

To test it, login to the trusted account as “TrustedUser”. We gave minimal permissions for the  “TrustedUser”, just enough to assume the role, so you will see many permissions warnings. However, you can choose “Switch Role”, supply the details, and gain access to the trusted account as before.

IAM is a free service, but if you want to clean up:

In the trusted account:

Delete the user “TrustedUer”

Delete the policy “AssumeCrossAcccountRole”

In the trusting account:

Delete the Role “CrossAccountRole

Search

Categories

  • ACM
  • AWS Directory Services for MS AD
  • CLI
  • CloudFront
  • Developing
  • DMS
  • EC2
  • EC2 Auto Scaling
  • ECS
  • File Gateway
  • Global Accelerator
  • IAM
  • KMS
  • Lambda
  • Macie
  • MicroServices
  • OpsWorks
  • Pricing
  • Private Link
  • Route 53
  • S3
  • SDK
  • Security
  • Serverless
  • SSO
  • Storage
  • Storage Gateway
  • Switching Roles
  • Transit Gateway
  • VPC
  • VPC Sharing
  • Well Architected Framework

Archives

  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • November 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • August 2018
  • April 2018

Tags

  • Advanced Archtecting
  • Alias
  • API Gateway
  • Aurora
  • AZ
  • CLI
  • CNAME
  • Cognito
  • Command Completion
  • Cross Account
  • DMS
  • DynamoDB
  • EC2
  • ECS
  • Facility
  • Fargate
  • Grants
  • IAM Policy Simulator
  • Instance Store
  • IPv6
  • Lambda
  • Macie
  • MFA
  • MicroServices
  • MySQL
  • Node.js
  • OpsWorks
  • Permissions Boundaries
  • Photo
  • Pre-Signed URLs
  • Pricing
  • Pricing Calculator
  • Private CA
  • S3
  • SDK
  • Simple Monthly Calculator
  • Snapshots
  • Spot
  • Step Functions
  • VPC
  • VPC Endpoint
  • Wild Rydes
  • WordPress
  • Workshop
  • X-Ray

Search

Proudly powered by WordPress