sts assume role via aws cli2

bogotobogo.com site search:

Assume role

In this post, we'll see how a user who has no access can have permission to AWS resource (here, S3) by assuming a role with Trust Relationship.

The makeup of an IAM role is the same as that of an IAM user and is only differentiated by the following qualities (How to use trust policies with IAM roles):

An IAM role does not have long term credentials associated with it; rather, a principal (an IAM user, machine, or other authenticated identity) assumes the IAM role and inherits the permissions assigned to that role.
The tokens issued when a principal assumes an IAM role are temporary. Their expiration reduces the risks associated with credentials leaking and being reused.
An IAM role has a trust policy that defines which conditions must be met to allow other principals to assume it. This trust policy reduces the risks associated with privilege escalation.

We have a user that has no AWS resources at all:

So, with current AWS credentials, the user cannot do aws s3 ls:

$ aws s3 ls

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

However, we can let the user access to S3 resources using AssumeRole.

An admin can make a role, test-role, that has Trust Relationships with the test-user:

The Trust Relationship looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxx:user/test-user"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

The role has a readonly access to S3:

Now, we want to get some credentials for the test-user to assume a role of test-role that has a permission to S3. Admin can issue the following assume-role command (check assume-role):

$ aws sts assume-role --role-arn arn:aws:iam::xxxxx:role/test-role \
--role-session-name s3-access-example --profile test-user  
{
    "Credentials": {
        "AccessKeyId": "ASIAXVB5JUJ6DHZSQM5K",
        "SecretAccessKey": "7p/V4ZIAFM2Ia1G4/Kqus86a8vOHWHRaK97k7toc",
        "SessionToken": "IQoJb3JpZ2luX2VjEHsaCXVzLWVhc3QtMSJHMEUCIE4EqnrwcZXNsc6VNm70AAM8tz5xU0c5aE9P756GqK3wAiEA3BE56jjWMv7iSn0upuXYxdy/5MQfJ7OikB4zvdvTwJEqpwII9P//////////ARADGgw1MjYyNjIwNTE0NTIiDCaVPO3OjmoxTjduUCr7AT/JbepKlGIHSwDkPwt+yg1SO0xoQUBM4xHtx9HljqmUS0nwe5TJxY36me4gJE2OoVn9qjh1+aRs1AfnUOEfKQzPljhEN/PjzMU72H1+hClSY89iegjDo1gWHwUBAVoWFOMaLEyuyy3/gniA0rUOlXTgaGXavVHPYIjvlwhH1imIIZvBuC1dckAkWsrOhw6IBH5zqP8+ZIwyd5INE0sWo6lUbuaGx0TIw38Jd0qt58K4qozdptPcAyeyUwN7noOZhxrHwsVNekzIzaINnhkZhj6xO5cby4yYtP790QdYo5stGXFan2uWylTarn9P7XRhcfqCShZvGbgWD2qqMM+oxoQGOp0BK1n9SD9jgW4A//BjqkHmKt2cYNuSthDMgU7mjyirnfmxa0fxRF8fRG0lLUK069pZQJnmrfMsVZTkSyBTaJ3MD6QLJJYzz0xY8utzdATNoPAf4TYjDv2FL2ugZLUp75Nifhqbfv2Lx8CmLrQxk8yNkCyaOSGubp/UtH5YVnRl1giNl/QrqEJyMPISILycqGc2O+qaBlzkIigzvr7MNQ==",
        "Expiration": "2021-05-04T19:37:03+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAXVB5JUJ6OVZSTC2H2:s3-access-example",
        "Arn": "arn:aws:sts::xxxxx:assumed-role/test-role/s3-access-example"
    }
}

The aws sts assume-role returns a set of temporary security credentials that we can use to access AWS resources that we might not normally have access to. These temporary credentials consist of an access key ID, a secret access key, and a security token.

Typically, we use AssumeRole within our account (as in this section) or for cross-account access.

As we can see the output of the command that contains an access key, secret key, and session token that we can use to authenticate to AWS.

As a test-user, we can set the following:

$ export AWS_ACCESS_KEY_ID=ASIAXVB5JUJ6DHZSQM5K
$ export AWS_SECRET_ACCESS_KEY=7p/V4ZIAFM2Ia1G4/Kqus86a8vOHWHRaK97k7toc
$ export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEHs...==

Then, the test-user can list S3 buckets:

$ aws s3 ls
2020-05-06 18:37:52 bogo-test-s3-terraform-bucket
2021-04-25 12:16:29 bogo-terraform-remote-state-bucket
2021-04-28 20:44:14 bogo-terraform-serverless-examplepy
...

We (admin or test-uer) can check who (an IAM user or a role) is calling operations, in our case, the "aws s3 ls" command:

$ aws sts get-caller-identity
{
    "UserId": "AROAVPSFGBEEGSNMUSQ3F:s3-access-example",
    "Account": "xxxxxxxxxxxx",
    "Arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/test-role/s3-access-example"
}

We see it's the assumed role, "test-role" that's because we set env variables with temporary credentials from "sts..." output for our "test-user".

It works!

Also, note that the credentials given via aws sts assuem-role are temporary, for 1 hour as indicated in "Credentials.Expiration" section of the command output.

Now we want to assume a role via AWS console.

We have a user (dummy-user) that has no AWS resources at all including S3:

But now the user wants to assume a role that can S3 read as shown below:

Try to switch:

Now, the dummy-user can read S3:

STS API Methods

AssumeRole
AssumeRole does require us to start with some basic AWS credentials, but those are allowed to be short-term ones as opposed to GetFederationToken.
AssumeRoleWithWebIdentity
AssumeRoleWithWebIdentity requires no AWS credentials to start with. Instead, it takes an external identity (Facebook etc.) and uses the trust policy built into the role to elevate AWS access for a short period of time.
AssumeRoleWithSAML
Same with AssumeRoleWithWebIdentity but it's used within AWS Organizations.
GetFederationToken
We must call the GetFederationToken action using the long-term security credentials of an IAM user. It scopes AWS credentials down in power (weaker) and time (shorter: up to 36h) so they can be handed out to someone else.
GetSessionToken