awslabs / aws-shell

An integrated shell for working with the AWS CLI.
Apache License 2.0
7.21k stars 776 forks source link

AWS_SESSION_TOKEN is ignored resulting in UnauthorizedOperation #212

Open remipichon opened 6 years ago

remipichon commented 6 years ago

summary

aws-shell doesn't seem to read the AWS_SESSION_TOKEN from the envs.

I recently switched to MFA for CLI which now prevents me to use aws-shell.

AWS configuration

Actual behaviour

$ aws-shell --profile dev
aws> ec2 describe-instances

An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.

same issue using .profile

$ aws-shell
aws> .profile dev
Current shell profile changed to: dev
aws> ec2 describe-instances

An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.
aws>

Expected behaviour

$ aws-shell --profile dev
aws> ec2 describe-instances
{
    "Reservations": []
}

Debug using aws cli

$ aws --profile dev ec2 describe-instances
{
    "Reservations": []
}

Steps to reproduce

pcgeek86 commented 5 years ago

Similar to your configuration, I have an AWS access key ID and secret key that I use, along with an MFA token, to generate a new:

Each time I renew my credentials, I write the updated profile back to my ~/.aws/credentials INI file as a secondary profile. When I use .profile myprofile2, then aws-shell uses the correct credentials and my API calls succeed.

[default]
aws_access_key_id=1234567890
aws_secret_access_key=1234567890
[stelligentmfa]
aws_secret_access_key=9999999999999999
aws_session_token=8888888888888888888888
aws_access_key_id=77777777777777
region=us-west-2

The difference between your configuration and my configuration is that I'm embedding the credentials vs. using the role_name attribute. I'm not sure how the latter is supposed to work. Also, I'm exclusively using the ~/.aws/credentials file, whereas you're using the ~/.aws/config file.

remipichon commented 5 years ago

The role_name attribute was correctly interpreted, solely using the ~/.aws/credentials doesn't rely fit a workflow where the session token is retrieved automagicaly by an external tool.

Thanks for the tip !

I guess this issue will not be picked any time soon, aws-shell is still a good tool though.

SuzakuTheKnight commented 2 years ago

I know this is old issue, but as it is still open and I encountered the issue as well, I wanted to leave behind my findings:

I was originally using using a combination of both ~/.aws/credentials and ~/.aws/config and getting the UnauthorizedOperation error:

~/.aws/credentials

[profile1]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>

~/.aws/config

[profile1]
region=us-gov-west-1

However, putting everything in the ~/.aws/credentials caused the issue to resolve.

~/.aws/credentials

[profile1]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>
region=us-gov-west-1

I suspect the logic that retrieves the session token for MFA accounts does not honor the region set in ~/.aws/config but does honor the region when set in ~/.aws/credentials .