How can I drop a assumed role?

Question

I have account A from which I assumed the role for account B. Now since my work is done I want to assume a role for account C. But since only Account A can assume a role for account C and B can't, I am unable to do so.

Any way I can invalidate/switch users for an assumed role? The minimum timeout is 15 mins which would be too much wait for a user.

Edit: Trying to achieve it via AWS CLI

Running below command:

aws sts assume-role --role-arn **** --role-session-name jenkins --external-id ****

Writhe

Is this question about the web interface, command-line tools, the API, or some kind of library? – Hamblin

Its for CLI ( running via jenkins ), appended the original question with this info. – Writhe

OK. Could you edit in a sample of the commands you're currently running? Remember that all the details that are obvious to you are completely invisible to anyone else unless you share them. – Hamblin

Answer 1

As I understood you use assume-role, you get a set of credentials like below

    {
        "AssumedRoleUser": {
            "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
            "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
        },
        "Credentials": {
            "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
            "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
            "Expiration": "2016-03-15T00:05:07Z",
            "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
        }
    }

Those credentials you export or use directly while running the command.

1. When you use them directly then you only using the credentials for the specific command, in the next command you are again back to Account A.

2. When you export, you easily call unset command to unset the exported var you'll be back to Account A and then you call assume-role again and export the credentials for account C.

Demodena

This did the trick ! Thanks a lot for the prompt response :) . – Writhe

glad was able to help. – Demodena

In my case the env was AWS_PROFILE – Wozniak

Answer 2

answering the question about how to re-assume a role(rather then 'dropping it') here:

while you can't directly 'revoke' session token using the aws cli or, 're-assume' a role when the role is specified as aws cli profile, you can achieve similar results by assuming the role directly by calling the sts:AssumeRole API using the aws CLI, and then setting AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_SESSION_TOKEN,AWS_DEFAULT_REGION as environment variable.

you can use this script to assume a role, and each invocation would override the session token with new one

#!/bin/bash

# Run aws sts assume-role and capture the output
assume_role_output=$(aws sts assume-role "$@" | cat)

# Extract temporary credentials from the output
export AWS_ACCESS_KEY_ID=$(echo $assume_role_output | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $assume_role_output | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $assume_role_output | jq -r '.Credentials.SessionToken')

# Extract AWS_DEFAULT_REGION from the --region parameter
AWS_DEFAULT_REGION=$(echo "$@" | awk -F'--region ' '{print $2}' | awk '{print $1}')
export AWS_DEFAULT_REGION

# Display the exported variables
echo "AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID"
echo "AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY"
echo "AWS_SESSION_TOKEN: $AWS_SESSION_TOKEN"
echo "AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION"

note that the previous session token would remain valid until expires(usually 1 hour).

usage:

~/development/aws/training ······································································································································· 19:55:14 ─╮
❯ source assume-role --profile mine --role-arn arn:aws:iam::************:role/mine-admin-role --role-session-name mine-role-session --region us-east-1                       ─╯
AWS_ACCESS_KEY_ID: ************
AWS_SECRET_ACCESS_KEY: ************
AWS_SESSION_TOKEN: ************
AWS_DEFAULT_REGION: us-east-1

 ~/development/aws/training ······································································································································· 20:07:53 ─╮
❯ aws sts get-caller-identity | cat                                                                                                                                          ─╯
{
    "UserId": "************:mine-role-session",
    "Account": "************",
    "Arn": "arn:aws:sts::************:assumed-role/mine-admin-role/mine-role-session"

note that are executing it with source so that the env variables would apply in your shell session. works like a charm.

Mastrianni

Thanks for sharing that, but what's the sense in " | cat "? It's a no-op in my understanding and just adding another process. Also, I think the OP is aware of that process, but want's to go back to the original AWS_SECRET_ACCESS_KEY, etc. – Ecstatics

" | cat " is necessary as by default aws sts assume role ... does not print the output to stdout but to hidden output (similar to echo hey | less ) to hide sensitive data to be printed to the stdout – Mastrianni

It may be OS specific. I never experienced "hidden output" and I just verified in Linux/Ubuntu the output of "aws sts ..." and "aws sts ... | cat " is only changing the same things that change anyway in between invocations. A pager, like less or more, should not kick in if there is no terminal, and the subshell "$(...)" should not have one. tldr; if it adds compatibility for some OS it might be an OK pattern, I do not believe it's necessary for Linux shells. – Ecstatics

Answer 3

You don't need to "drop" the assumed role if you're using CLI.

You should use named profiles and execute commands in different accounts by specifying profile name explicitly with --profile CLI switch, or alternatively by changing AWS_PROFILE env variable between commands.

Madiemadigan

Unfortunately setting AWS_PROFILE to, say, default profile still tries to execute commands on behalf of the previously assumed role. – Toby

@Viji, you probably didn't clear out all the AWS_* environment variables from your environment. You could try wrapping the commands that set the environment variables with '(' and ')'. Outside the parentheses, anything set in the environment disappears, and you are back to your default profile. – Bulletin