coinbase / assume-role Goto Github PK

View Code? Open in Web Editor NEW

423.0 423.0 74.0 1.09 MB

DEPRECATED — assume-role: a CLI tool making it easy to assume IAM roles through an AWS Bastion account

License: Apache License 2.0

Shell 98.79% Makefile 1.21%

assume-role's People

Contributors

Stargazers

Watchers

assume-role's Issues

Share STS session between different shells

I use screen heavily, and it's a pain to either have to enter an MFA token into any shell window I want to run a command from or run all my commands from just one shell.

assume-role already has an extra file in ~/.aws (accounts). What would you think of persisting what's currently kept in the AWS_SESSION_* environment variables in a new file ~/.aws/session? assume-role-with-bastion would read that file at the beginning and rewrite it on success. This way, no matter what shell you run assume-role prod rolename from, it will use the same STS token.

ENV gets tainted when assume-role fails with wrong MFA

👋 hello Coinbase,
I think I've found a bug in the way assume-role and aws interact with each other.
I'm using a standard AWS Bastion setup, with minimal accounts, config and credentials file as described in the README. My shell (zsh) ENV is quite vanilla as well:

% env | grep AWS
%

assume-role usually works fine for me but here's how to trigger the bug:

# start with the empty ENV as above
% env | grep AWS
% 

# now type in a wrong MFA token, something like 12345
% assume-role foo bar
MFA Token:
Parameter validation failed:
Invalid length for parameter TokenCode, value: 5, valid range: 6-inf
aws sts get-session-token error

# let's have a look at ENV
% env | grep AWS
AWS_SESSION_START=0

# now try again, with a correct value
# also notice the double dots in the IAM endpoint
% assume-role foo bar
MFA Token:
Invalid endpoint: https://iam..amazonaws.com
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: argument --user-name: expected one argument
aws iam list-mfa-devices error

# and let's have a look at ENV again
% env | grep AWS
AWS_SESSION_START=0
AWS_SESSION_ACCESS_KEY_ID=
AWS_SESSION_SECRET_ACCESS_KEY=
AWS_SESSION_SESSION_TOKEN=
AWS_REGION=
AWS_DEFAULT_REGION=
AWS_ACCOUNT_ID=
AWS_ACCOUNT_NAME=
AWS_ACCOUNT_ROLE=

The error reported above is exactly the same when you set default region to an empty string:

# empty ENV
% env | grep AWS
%

# this works
% aws iam get-user --query User.UserName --output text
...

# aws doesn't touch ENV
% env | grep AWS
%

# with this, it stops working
% export AWS_DEFAULT_REGION=''
% aws iam get-user --query User.UserName --output text

Invalid endpoint: https://iam..amazonaws.com

# just in case
% env | grep AWS
AWS_DEFAULT_REGION=

A workaround I've found is to export AWS_DEFAULT_REGION in my shell, this diff works as well:

diff --git a/assume-role b/assume-role
index 2cc338a..cc1eb87 100755
--- a/assume-role
+++ b/assume-role
@@ -144,6 +144,8 @@ assume-role(){
     echo_out "region not defined"
     return
   fi
+  AWS_REGION="$region"
+  AWS_DEFAULT_REGION="$region"

   # Activate our session
   NOW=$(date +"%s")

I still don't know why this is happening: it might very well be a bug in aws or undocumented behaviour. For sure, tainting ENV with AWS_SESSION_START=0 is not enough and you have to export AWS_DEFAULT_REGION as an empty string to trigger this abnormal behaviour, this is why globally setting a default region fixed it. But honestly, it escapes me why this is only happening when you fail your MFA request at least once 😄

JSON output required

Pretty unlikely that most people will be hitting this issue, but I needed to set the default output value in ~/.aws/config (example below) before opening a terminal to run assume-role or I would get error regarding invalid endpoint. Maybe there should be a safety check for this value to be present?

Required minimum config:

[default]
output = json

Example of error if output value is missing:

> assume-role staging read
MFA Token:
Invalid endpoint: https://iam..amazonaws.com
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: argument --user-name: expected one argument
aws iam list-mfa-devices error

Feature Request: Read Accounts & Roles from config file

~/.aws/config

[profile iam]
 region = eu-central-1

[profile production]
source_profile = iam
role_arn = arn:aws:iam::1234567890:role/Administrator
region = eu-central-1

aws cli expects AWS_DEFAULT_REGION

Very useful tool, just discovered one small thing, it appears the expected env var is AWS_DEFAULT_REGION instead of AWS_REGION.

p.s. also discovered a neat bonus feature, that if you're juggling multiple accounts (e.g. home, work) and want to use a profile besides default, you can invoke assume-role like:

AWS_PROFILE=your-non-default-profile assume-role your-account your-role your-code

Great stuff, thanks!

Improved fish support

Hi, I was able to improve the fish shell support, but wanted to check with you if that is an approach you would support before creating a PR:

Basically I took over your "init" stub and named it shell. It shall output an "eval"-able result:

elif [[ "shell" == "${1}" ]]; then
  # TODO: This will be multi-shell support like rbenv, e.g. fish
  # Supports "assume-role shell [account] [role]" | <translate syntax> | source in your favourite shell
  set -eo pipefail
  OUTPUT_TO_EVAL="true"
  shift
  assume-role "$@";

BUT to enable the interactive mfa prompt (which I really want to have with fish) I had to redirect the prompt to stderr:

    if [ -z "$mfa_token_input" ]; then            # removed: && [ -z "$OUTPUT_TO_EVAL" ]
      echo -n "MFA Token: " >> /dev/stderr  # redirected user prompts to stderr - should this be used everywhere to enable interactive prompts when caledl via eval or source pipe?
      read -r -s mfa_token

You can now have a function like this in fish:

function role2
   assume-role shell $argv | sed 's/^export/set -x --global/' | sed 's/=/ /' | source
end

Is that an approach worth to follow for you? Any suggestions for improvements?

Jan

How to specify external ID in sts assume-role call?

When assuming a cross-account role in a customer’s account, I need to specify an external ID that’s associated with that customer. [1] It seems currently the assume-role function always uses the account ID of the target account as the external ID:

assume-role/assume-role

Line 356 in 860f895

ROLE_SESSION_ARGS+=(--external-id "${account_id}")

I’m not sure what would be the best way to specify the external ID:

Adding another positional command parameter to the function seems doable but not very usable. I’d really just like to specify the target account name and lookup the associated external ID automatically.
The ~/.aws/accounts seems the obvious place to store this mapping, but the existing format of the file doesn’t lend itself to such an extension easily. Maybe the account name could map to an object with accountId and externalId (optional) keys?
Or we could add a new file to store this mapping, e.g. ~/.aws/externalIds.

Any other suggestions? I’d be happy to help with the implementation and provide a PR, if I could get some guidance on which approach would likely be accepted.

[1] How to Use an External ID When Granting Access to Your AWS Resources to a Third Party: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

account_id "xxxxxxxxxxx" is incorrectly formatted AWS account id

When using the ~/.aws/accounts file AWS account ids that start with a 0 (zero) throw the error account_id "xxxxxxxxxxx" is incorrectly formatted AWS account id

It seems that because the id is specified as a json number the leading zero is removed. Then if the id is specified as a string the following error is thrown.

account_id ""xxxxxxxxxxxx"" is incorrectly formatted AWS account id

I think the solution is to use jq --raw-output on the account_id look up. However there may have been a good reason to use a number for the account id, I've only just started using this.

Can't assume-role for longer than an hour (AWS limitation?)

[UPDATE: This appears to be an AWS limitation? After many attempts with assume-role, and after recreating the issue using vanilla AWSCLI commands, it appears that you cannot assume a role for longer than an hour using temporary credentials generated with aws sts get-session-token. (See this AWS forum thread for more info. If anyone else is able to do this I'd be very grateful to know how you do it. Thanks!]

I set up assume-role as described in the README. I am attempting to assume a role IAMAdmin with user credentials on the same account. I am able to switch roles in the console, but when I try it with assume-role I get this error:

$ assume-role iam IAMAdmin 030460
Using assume-role default profile: iam

An error occurred (ValidationError) when calling the AssumeRole operation: The requested DurationSeconds exceeds the 1 hour session limit for roles assumed by role chaining.
Failed to export session envars.

I don't think I am doing role chaining--I am just trying to assume a role as a user. Any thoughts on why I'd see this?

UPDATE:
I was also able to assume the role by using the CLI directly:

$ aws sts assume-role --role-arn arn:aws:iam::000000000000:role/IAMAdmin --role-session-name testsession --profile iam --duration-seconds 43200 --serial-number arn:aws:iam:: 000000000000:mfa/David.Ham --token-code 994032
{
    "Credentials": {
        "AccessKeyId": "ASIAREDACTEDCITA",
        "SecretAccessKey": "eNA0yCXL0REDACTED",
        "SessionToken": "<REDACTED>",
        "Expiration": "2018-06-01T02:37:56Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAJYQJREDACTED:testsession",
        "Arn": "arn:aws:sts:: 000000000000:assumed-role/IAMAdmin/testsession"
    }
}

"mfa_token is not defined" when attempting to assume role

Hi all, thanks for this project!

When I run assume-role production read, I receive the following error:

echo "mfa_token is not defined";

Providing the MFA token after read, it does work, but this behavior appears to contradict the README.

Parameter validation failed

Hey,
I get an error after upgrading to version 0.1.4

Parameter validation failed:
Invalid length for parameter SerialNumber, value: 4, valid range: 9-inf

the version 0.1.3 is still working for me. Do you have an idea where the error is coming from?

Regards
putarpuar

`source $(which assume-role)` broken

Since #53 we can no longer source $(which assume-role) in .zshrc, it fails with exit 1:

➜  ~ source $(which assume-role)
 assume-role is a command line tool to help assume roles through a bastion account with MFA.
 Store your bastion account credentials here ~/.aws/credentials

 Usage: assume-role [account_name] [role] [mfa_token] [aws-region]

 account_name          account id or alias
                       aliases stored in ~/.aws/accounts as JSON {"alias": account_id}
                       [default 'default']
 role                  the role to assume into the account
                       [default 'read']
 mfa_token             The MFA token for the user
                       only valid if not using SAML for auth

 aws_region            region to assume into default set in ~/.aws/config
Error: exit status 1
exit status 1

I think it's because of how this gets evaluated without args on source:

assume-role/assume-role

Lines 41 to 44 in 860f895

 if [ $# -eq 0 ] ; then 

 usage; 

 exit 1; 

 fi

The documentation states that this should be possible, and we've been able to do this successfully until this recent change.

assume-role/README.md

Line 52 in 860f895

 If your shell supports bash functions (e.g. zsh) then you can add `source $(which assume-role)` to your `rc` file (e.g. `~/.zshrc`), then you can call `assume-role` like: 

Invalid length for parameter SAMLAssertion, value: 0, valid range: 4-inf

Hello and thank you for the excellent assume-role tool. I have it working when using an IAM user in a bastion account, but I am now attempting to convert my usage over to a SAML integration with Okta, and running into issues.

I have the following env vars set (among others) in my .bashrc file.

export AWS_ASSUME_ROLE_AUTH_SCHEME='saml' # defaults to bastion
export SAML_IDP_ASSERTION_URL="https://redacted.okta.com/app/amazon_aws/redactedhash/sso/saml"
export SAML_IDP_NAME="name-of-my-idp-in-aws"
export SAML_IDP_REQUEST_BODY_TEMPLATE='{"service": "aws", "email": "$saml_user", "password": "$saml_password"}'

I used a URL found in my AWS identity provider metadata to populate that SAML_IDP_ASSERTION_URL

However, when I attempt to authenticate using the CLI, I get the following errors:

Gathering SAML credentials...
Password: 
Authenticating with SAML provider...
parse error: Invalid numeric literal at line 1, column 10

Parameter validation failed:
Invalid length for parameter SAMLAssertion, value: 0, valid range: 4-inf

Any suggestions?

Tokens expire after an hour

My understanding is that the session tokens last for 12 hours, but the assumerole credentials that come back only last for an hour.

Are you re-running this every hour? What do you do for processes which need more than hour to complete? For some apps I've re-written them to handle their own tokens, but how do you handle this on your team?

Can't understand tests failure and SAML implementation

Hi,

The project seems to be good, but the bats test systematically fails, and also in my case I was looking for a solution for switch role with SAML through a security account (bastion) where the SAML idp is registered but It seems like the SAML implementation here always require MFA token, or doesn't work.

I was not able to use the solution in definitive.

bash-3.2$ bats test/assume-role.bats
 ✗ should work for the bastion auth scheme
   (in test file test/assume-role.bats, line 96)
     `[ "${lines[0]}" = 'echo "Success! IAM session envars are exported.";' ]' failed
   0: echo "Using assume-role default profile: bastion";
   1: echo "Success! IAM session envars are exported.";
   2: export AWS_REGION="us-east-1";
   3: export AWS_DEFAULT_REGION="us-east-1";
   4: export AWS_ACCESS_KEY_ID="role_key_id";
   5: export AWS_SECRET_ACCESS_KEY="role_secret_key";
   6: export AWS_SESSION_TOKEN="role_session_token";
   7: export AWS_ACCOUNT_ID="123456789012";
   8: export AWS_ACCOUNT_NAME="dev";
   9: export AWS_ACCOUNT_ROLE="look_around";
   10: export AWS_SESSION_ACCESS_KEY_ID="session_key_id";
   11: export AWS_SESSION_SECRET_ACCESS_KEY="session_secret_key";
   12: export AWS_SESSION_SESSION_TOKEN="session_session_token";
   13: export AWS_SESSION_SECURITY_TOKEN="session_session_token";
   14: export AWS_SESSION_START="1552410525";
   15: export GEO_ENV="dev";
   16: export AWS_PROFILE_ASSUME_ROLE="bastion";
   17: export AWS_SECURITY_TOKEN="role_session_token";
   18: AWS_CONFIG_REGION="nz-north-1";
   19: AWS_USERNAME="aws_username";
   20: MFA_DEVICE_ARGS="--user-name aws_username --query MFADevices[0].SerialNumber --output text --profile bastion";
   21: MFA_DEVICE="arn:aws:iam::123456789012:mfa/BobsMFADevice";
   22: SESSION_ARGS="--duration-seconds 43200 --serial-number arn:aws:iam::123456789012:mfa/BobsMFADevice --token-code 123456 --profile bastion --output json";
   23: SESSION="{"Credentials":{"SecretAccessKey":"session_secret_key","SessionToken":"session_session_token","Expiration":"2000-10-11T05:12:25Z","AccessKeyId":"session_key_id"}}";
   24: ROLE_SESSION_ARGS="--role-arn arn:aws:iam::123456789012:role/look_around --external-id 123456789012 --duration-seconds 43200 --role-session-name 1552410525";
   25: ROLE_SESSION="{"Credentials":{"SecretAccessKey":"role_secret_key","SessionToken":"role_session_token","Expiration":"2017-10-11T05:12:25Z","AccessKeyId":"role_key_id"}}";
   26: SESSION_TIMEOUT="43200";
   27: ROLE_SESSION_TIMEOUT="43200";
   28: AWS_PROFILE_ASSUME_ROLE="bastion";
 ✗ should work for the SAML auth scheme
   (in test file test/assume-role.bats, line 126)
     `[ "${lines[0]}" = 'echo "Gathering SAML credentials...";' ]' failed
   0: echo "Using assume-role default profile: bastion";
   1: echo "Gathering SAML credentials...";
   2: echo "Authenticating with SAML provider...";
   3: echo "Success! IAM session envars are exported.";
   4: export AWS_REGION="us-east-1";
   5: export AWS_DEFAULT_REGION="us-east-1";
   6: export AWS_ACCESS_KEY_ID="role_key_id";
   7: export AWS_SECRET_ACCESS_KEY="role_secret_key";
   8: export AWS_SESSION_TOKEN="role_session_token";
   9: export AWS_ACCOUNT_ID="123456789012";
   10: export AWS_ACCOUNT_NAME="dev";
   11: export AWS_ACCOUNT_ROLE="look_around";
   12: export AWS_SESSION_ACCESS_KEY_ID="";
   13: export AWS_SESSION_SECRET_ACCESS_KEY="";
   14: export AWS_SESSION_SESSION_TOKEN="";
   15: export AWS_SESSION_SECURITY_TOKEN="";
   16: export AWS_SESSION_START="";
   17: export GEO_ENV="dev";
   18: export AWS_PROFILE_ASSUME_ROLE="bastion";
   19: export AWS_SECURITY_TOKEN="role_session_token";
   20: AWS_CONFIG_REGION="nz-north-1";
   21: AWS_USERNAME="";
   22: MFA_DEVICE_ARGS="";
   23: MFA_DEVICE="";
   24: SESSION_ARGS="";
   25: SESSION="";
   26: ROLE_SESSION_ARGS="--role-arn arn:aws:iam::123456789012:role/look_around --principal-arn arn:aws:iam::123456789012:saml-provider/saml-test-idp --saml-assertion aGVsbG8= --duration-seconds 43200";
   27: ROLE_SESSION="{"Credentials":{"SecretAccessKey":"role_secret_key","SessionToken":"role_session_token","Expiration":"2017-10-11T05:12:25Z","AccessKeyId":"role_key_id"}}";
   28: SESSION_TIMEOUT="43200";
   29: ROLE_SESSION_TIMEOUT="43200";
   30: AWS_PROFILE_ASSUME_ROLE="bastion";
 ✗ should fail if the account_id is bad
   (in test file test/assume-role.bats, line 146)
     `[ "${lines[0]}" = 'echo "account_id "12345678901212354" is incorrectly formatted AWS account id";' ]' failed
   0: echo "Using assume-role default profile: bastion";
   1: echo "account_id "12345678901212354" is incorrectly formatted AWS account id";
 ✗ should work if the account_id is a string
   (in test file test/assume-role.bats, line 152)
     `[ "${lines[6]}" = 'export AWS_ACCOUNT_ID="012345678901";' ]' failed
   0: echo "Using assume-role default profile: bastion";
   1: echo "Success! IAM session envars are exported.";
   2: export AWS_REGION="eu-central-1";
   3: export AWS_DEFAULT_REGION="eu-central-1";
   4: export AWS_ACCESS_KEY_ID="role_key_id";
   5: export AWS_SECRET_ACCESS_KEY="role_secret_key";
   6: export AWS_SESSION_TOKEN="role_session_token";
   7: export AWS_ACCOUNT_ID="012345678901";
   8: export AWS_ACCOUNT_NAME="string";
   9: export AWS_ACCOUNT_ROLE="sudo";
   10: export AWS_SESSION_ACCESS_KEY_ID="session_key_id";
   11: export AWS_SESSION_SECRET_ACCESS_KEY="session_secret_key";
   12: export AWS_SESSION_SESSION_TOKEN="session_session_token";
   13: export AWS_SESSION_SECURITY_TOKEN="session_session_token";
   14: export AWS_SESSION_START="1552410526";
   15: export GEO_ENV="string";
   16: export AWS_PROFILE_ASSUME_ROLE="bastion";
   17: export AWS_SECURITY_TOKEN="role_session_token";
   18: AWS_CONFIG_REGION="nz-north-1";
   19: AWS_USERNAME="aws_username";
   20: MFA_DEVICE_ARGS="--user-name aws_username --query MFADevices[0].SerialNumber --output text --profile bastion";
   21: MFA_DEVICE="arn:aws:iam::123456789012:mfa/BobsMFADevice";
   22: SESSION_ARGS="--duration-seconds 43200 --serial-number arn:aws:iam::123456789012:mfa/BobsMFADevice --token-code 123456 --profile bastion --output json";
   23: SESSION="{"Credentials":{"SecretAccessKey":"session_secret_key","SessionToken":"session_session_token","Expiration":"2000-10-11T05:12:25Z","AccessKeyId":"session_key_id"}}";
   24: ROLE_SESSION_ARGS="--role-arn arn:aws:iam::012345678901:role/sudo --external-id 012345678901 --duration-seconds 43200 --role-session-name 1552410526";
   25: ROLE_SESSION="{"Credentials":{"SecretAccessKey":"role_secret_key","SessionToken":"role_session_token","Expiration":"2017-10-11T05:12:25Z","AccessKeyId":"role_key_id"}}";
   26: SESSION_TIMEOUT="43200";
   27: ROLE_SESSION_TIMEOUT="43200";
   28: AWS_PROFILE_ASSUME_ROLE="bastion";
 ✗ should assign the account_id if provided
   (in test file test/assume-role.bats, line 158)
     `[ "${lines[6]}" = 'export AWS_ACCOUNT_ID="111111111111";' ]' failed
   0: echo "Using assume-role default profile: bastion";
   1: echo "Success! IAM session envars are exported.";
   2: export AWS_REGION="eu-central-1";
   3: export AWS_DEFAULT_REGION="eu-central-1";
   4: export AWS_ACCESS_KEY_ID="role_key_id";
   5: export AWS_SECRET_ACCESS_KEY="role_secret_key";
   6: export AWS_SESSION_TOKEN="role_session_token";
   7: export AWS_ACCOUNT_ID="111111111111";
   8: export AWS_ACCOUNT_NAME="111111111111";
   9: export AWS_ACCOUNT_ROLE="sudo";
   10: export AWS_SESSION_ACCESS_KEY_ID="session_key_id";
   11: export AWS_SESSION_SECRET_ACCESS_KEY="session_secret_key";
   12: export AWS_SESSION_SESSION_TOKEN="session_session_token";
   13: export AWS_SESSION_SECURITY_TOKEN="session_session_token";
   14: export AWS_SESSION_START="1552410526";
   15: export GEO_ENV="111111111111";
   16: export AWS_PROFILE_ASSUME_ROLE="bastion";
   17: export AWS_SECURITY_TOKEN="role_session_token";
   18: AWS_CONFIG_REGION="nz-north-1";
   19: AWS_USERNAME="aws_username";
   20: MFA_DEVICE_ARGS="--user-name aws_username --query MFADevices[0].SerialNumber --output text --profile bastion";
   21: MFA_DEVICE="arn:aws:iam::123456789012:mfa/BobsMFADevice";
   22: SESSION_ARGS="--duration-seconds 43200 --serial-number arn:aws:iam::123456789012:mfa/BobsMFADevice --token-code 123456 --profile bastion --output json";
   23: SESSION="{"Credentials":{"SecretAccessKey":"session_secret_key","SessionToken":"session_session_token","Expiration":"2000-10-11T05:12:25Z","AccessKeyId":"session_key_id"}}";
   24: ROLE_SESSION_ARGS="--role-arn arn:aws:iam::111111111111:role/sudo --external-id 111111111111 --duration-seconds 43200 --role-session-name 1552410526";
   25: ROLE_SESSION="{"Credentials":{"SecretAccessKey":"role_secret_key","SessionToken":"role_session_token","Expiration":"2017-10-11T05:12:25Z","AccessKeyId":"role_key_id"}}";
   26: SESSION_TIMEOUT="43200";
   27: ROLE_SESSION_TIMEOUT="43200";
   28: AWS_PROFILE_ASSUME_ROLE="bastion";
 ✗ should fail if style is bad
   (in test file test/assume-role.bats, line 162)
     `shellcheck ./assume-role' failed

   In ./assume-role line 180:
     elif [ ! -z "$aws_region_input" ]; then
            ^-- SC2236: Use -n instead of ! -z.


   In ./assume-role line 183:
     elif [ ! -z "$AWS_REGION" ]; then
            ^-- SC2236: Use -n instead of ! -z.


   In ./assume-role line 186:
     elif [ ! -z "$AWS_DEFAULT_REGION" ]; then
            ^-- SC2236: Use -n instead of ! -z.


   In ./assume-role line 189:
     elif [ ! -z "$AWS_CONFIG_REGION" ]; then
            ^-- SC2236: Use -n instead of ! -z.

   For more information:
     https://www.shellcheck.net/wiki/SC2236 -- Use -n instead of ! -z.

6 tests, 6 failures
bash-3.2$ cat ~/.bashrc
# AWS ACCOUNT NAME
function aws_account_info {
  [ "$AWS_ACCOUNT_NAME" ] && [ "$AWS_ACCOUNT_ROLE" ] && echo "%F{blue}aws:(%f%F{red}$AWS_ACCOUNT_NAME:$AWS_ACCOUNT_ROLE%f%F{blue})%F$reset_color"
}

# )ofni_tnuocca_swa($ is $(aws_account_info) backwards

My .bashrc

PROMPT=`echo $PROMPT | rev | sed 's/ / )ofni_tnuocca_swa($ /'| rev`

export DEBUG_ASSUME_ROLE="true" # turns on debugging
export ACCOUNTS_FILE="~/.aws/accounts"
export SAML_FILE="~/.aws/saml_creds"
export SAML_IDP_ASSERTION_URL="https://www.mydomain.com"
export SAML_IDP_REQUEST_BODY_TEMPLATE="{\"service\": \"aws\", \"email\": \"[email protected]\", \"password\": \"Lct,j'mp11\"}"
export AWS_ROLE_SESSION_TIMEOUT=43200
export AWS_DEFAULT_REGION="eu-central-1"
export AWS_PROFILE_ASSUME_ROLE="bastion"
bash-3.2$

Does not work without MFA

script Does not work without MFA.

assume-role 123456789012 Administrator
echo "mfa_token is not defined";

FR: Output ACCOUNT_ROLE if called via 'eval'

Hi, great work on the tool! I try to write a wrapper for the fish-shell and it would be helpful if you can output the ACCOUNT_ROLE here so I can add it to the prompt:

https://github.com/coinbase/assume-role/blob/master/assume-role#L238-L249

  # OUTPUTS ALL THE EXPORTS for eval $(assume-role [args])
  if [ "$OUTPUT_TO_EVAL" = "true" ]; then
    echo "export AWS_REGION=\"$AWS_REGION\";"
    echo "export AWS_DEFAULT_REGION=\"$AWS_DEFAULT_REGION\";"
    echo "export AWS_ACCESS_KEY_ID=\"$AWS_ACCESS_KEY_ID\";"
    echo "export AWS_SECRET_ACCESS_KEY=\"$AWS_SECRET_ACCESS_KEY\";"
    echo "export AWS_SESSION_TOKEN=\"$AWS_SESSION_TOKEN\";"
    echo "export AWS_ACCOUNT_ID=\"$AWS_ACCOUNT_ID\";"
    echo "export AWS_ACCOUNT_NAME=\"$AWS_ACCOUNT_NAME\";"
    echo "export AWS_SESSION_ACCESS_KEY_ID=\"$AWS_SESSION_ACCESS_KEY_ID\";"
    echo "export AWS_SESSION_SECRET_ACCESS_KEY=\"$AWS_SESSION_SECRET_ACCESS_KEY\";"
    echo "export AWS_SESSION_SESSION_TOKEN=\"$AWS_SESSION_SESSION_TOKEN\";"
    echo "export AWS_SESSION_START=\"$AWS_SESSION_START\";"
    echo "export GEO_ENV=\"$GEO_ENV\";"
  fi

Support for YubiKey as multi-factor authentication

Now is possible to use a YubiKey as MFA device
https://aws.amazon.com/blogs/security/use-yubikey-security-key-sign-into-aws-management-console/

assume-role works with OTP only. do you have any plans to support YubiKeys?

assume-role failing due to python errors

Hi,

recently I had installed anaconda but due to disk space issues, I had to delete the whole anaconda stack and tried using the default python, but assume-role always fails with the following error.

$ assume-role dev admin
Using assume-role default profile: securezapp-root
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000000011954d5c0 (most recent call first):
MFA Token: ******

Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000000010e9955c0 (most recent call first):
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x0000000112d165c0 (most recent call first):
aws iam list-mfa-devices error

I have tried the following things,
https://stackoverflow.com/questions/5694706/py-initialize-fails-unable-to-load-the-file-system-codec/45423949#45423949

brew install python3
cd /usr/local/bin
rm python3
ln -s /usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/‌Versions/3.7/bin/pyt‌hon3.7 /usr/local/bin/python3

I dont know how to resolve this problem and I have been working on this for a day now, any help would be greatly appreciated.

Syntax error when trying to source function in bash

The Getting Started section of the readme suggests that it should be possible to source the assume-role function so that it can be used without eval. I'm getting a syntax error when I try to do that:

$ source $(which assume-role)
-bash: /usr/local/bin/assume-role: line 396: syntax error near unexpected token `('
-bash: /usr/local/bin/assume-role: line 396: `cleanup() {'

System info:

$ echo $SHELL
/usr/local/bin/bash

$ /usr/local/bin/bash --version
GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.3.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ brew info assume-role
coinbase/assume-role/assume-role: stable 0.3.0
https://github.com/coinbase/assume-role
/usr/local/Cellar/assume-role/0.3.0 (5 files, 34.8KB) *
  Built from source on 2019-02-27 at 15:51:06
From: https://github.com/coinbase/homebrew-assume-role/blob/master/assume-role.rb
==> Dependencies
Required: awscli ✔, jq ✔

$ source /usr/local/Cellar/assume-role/0.3.0/bin/assume-role
-bash: /usr/local/Cellar/assume-role/0.3.0/bin/assume-role: line 396: syntax error near unexpected token `('
-bash: /usr/local/Cellar/assume-role/0.3.0/bin/assume-role: line 396: `cleanup() {'

coinbase / assume-role Goto Github PK

assume-role's People

Contributors

Stargazers

Watchers

Forkers

assume-role's Issues

Recommend Projects

Recommend Topics

Recommend Org