AWS_SESSION_TOKEN is ignored resulting in UnauthorizedOperation

[Remi Pichon]

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

• aws server side details

  • a main account with my user
  • a secondary account to be accessed using an assumed role that enforce MFA

• .aws/config

[default]
region = eu-west-1
output = json
[profile dev]
role_arn = <redacted>
credential_source = Environment
region = eu-west-1
output = json

• environment

$ env | grep AWS
AWS_SESSION_TOKEN=<redacted>
AWS_SECRET_ACCESS_KEY=<redacted>
AWS_ACCESS_KEY_ID=<redacted>

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

• enable MFA on an assumed role
• get temporary token using aws sts get-session-token --serial-number arn:aws:iam::<account>:mfa/<username> --token-code <mfa-token>
• store them in ENV and configure profile credential source to be Environment

[Trevor Sullivan]

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:

• Access Key ID
• Secret Key
• STS Session Token

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.

[Remi Pichon]

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]

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 .