Reputation: 86097
I'm constantly getting this error:
An error occurred (InvalidClientTokenId) when calling the AssumeRole operation: The security token included in the request is invalid.
when I run this Assume Role command:
aws sts assume-role --role-arn <arn role i want to assume> --role-session-name dev --serial-number <my arn> --token-code <keyed in token code>
This was working previously so I'm not sure what could have changed. And at a loss at how to debug this.
Any suggestions?
Upvotes: 35
Views: 113729
Reputation: 1
I was having the same issue, however in my case I was returning to a project after some months on others and my access key in IAM > users > my user > security credentials was set to inactive. Reactivating it fixed the problem.
Upvotes: 0
Reputation: 392
In my case, I set AWS credentials in the Windows environment variables and forgot about it, so each time AWS CLI reads from the environment variables, not from .aws/credentials. The problem is fixed after removing the environment variables and setting the correct credentials
Upvotes: 0
Reputation: 11
This solution works for me after trying all solutions listed here.
I had to add aws_session_token
in the ~/.aws/credentials (on mac) file along with aws_access_key_id
and aws_session_token
.
Upvotes: 0
Reputation: 71
My problem was I changed my phone (authentication device) I had to remove the MFA and then create a new one. On the way I updated my password
Upvotes: 0
Reputation: 76
Same error, but with a very specific situation and solution. In my case I have a profile that assumes a role in my .aws/credentials
like the following:
[name]
role_arn = arn:aws:iam::ACCOUNT:role/ROLE_NAME
source_profile = default
I was working on the role, and while doing so deleted and recreated it. AWS CLI caches the token when using this profile method. The cached token was for the old role not the recreated one. This can be seen by adding --debug
to the CLI command:
2023-01-27 16:22:03,055 - MainThread - botocore.credentials - DEBUG - Credentials for role retrieved from cache.
2023-01-27 16:22:03,055 - MainThread - botocore.credentials - DEBUG - Retrieved credentials will expire at: 2023-01-27 21:46:59+00:00
The cache can be wiped by removing the ~/.aws/cli/cache
directory or the specific JSON file for this session found inside that directory.
Upvotes: 1
Reputation: 1275
I've got this error when I was trying to connect to my localstack instance.
The cause was the missing --endpoint-url http://localhost:4566
argument for aws
cli.
Upvotes: 0
Reputation: 37
Let's not forget the simplest of things. I got this same exact error message when I did not have a default region set. You can set it by running aws configure. Or, you can pass the region on sts command like so.
aws sts assume-role --role-arn "your_role_arn" --role-session-name MySessionName --region us-gov-west-1
Upvotes: 0
Reputation: 12259
Make sure the target AWS region is enabled. Here is how you can enable a region.
Upvotes: 1
Reputation: 11
Fixed this issue by re-activating my access keys in iam user credentials section of your user. It was in-active when I got this issue.
Upvotes: 1
Reputation: 1
I have tried to create on fly ~/.aws/config file with multi-profile to give my code build multi-account access. I made a mistake when I first create the file ~/.aws/config with an empty default profile and then tried to assume the role.
When you put the file ~/.aws/config in a place with a default profile, it is the profile that determines the identity and not the one that comes with the CodeBuild.
Upvotes: 0
Reputation: 6526
TLDR; The IAM user's key/secret key is one set of credentials. The session token + session's key/secret key are a different set of credentials, with different values.
--
I did not know the aws sts
command created a session token, and new a AWS key/secret key. These keys are not the same as your IAM user key and secret key.
I generated a new key, secret key, and token. I updated my credentials file to use the new values. When my token expired the next day, I re-ran the aws sts
command. However, the key and secret key in the credentials file were now wrong. I replaced the key and secret key values my IAM user keys in my credentials file. I also delete the session token in my credentials file.
Then the aws sts
command worked.
Upvotes: 1
Reputation: 111
Check your aws_access_key_id
and aws_secret_access_key
are correct in the ~/.aws/credentials
file.
If they are then if the ~/.aws/credentials
file contains a aws_session_token
delete only that line in the file, save your changes and re-run your command.
Worked for me.
Upvotes: 11
Reputation: 61
I noticed that when I had to change my AWS IAM password, my access keys were also erased.
I had to generate a new access key and replace the aws_access_key_id
and aws_secret_access_key
stored in the ~/.aws/credentials
(on mac) file.
This cleared the error
Upvotes: 6
Reputation: 31
You need to do an aws configure
and set the AWS access key and secret key on the environment where you are running the STS command if its the first time you are running. The STS command verifies the identity using that data and checks if you have permissions to perform STS assume-role.
If you already have an existing access key and secret key configured, it could be possible that those have also been expired. So you might need to generate new keys for the user in IAM and configure it in the environment you are running.
Upvotes: 3
Reputation: 11896
Here you need to reset your aws secret key and ID like -
export AWS_ACCESS_KEY_ID='ACCESS_KEYID';
export AWS_SECRET_KEY='SECRET_KEY'
in my case I use command aws configure
in terminal for cli
and it asks for access key id, secret key, region and output format.
Upvotes: 1
Reputation: 1703
I had the same problem. You may need to unset your AWS env variables before running the sts command:
unset AWS_SECRET_ACCESS_KEY
unset AWS_SECRET_KEY
unset AWS_SESSION_TOKEN
and then your command:
aws sts assume-role --role-arn <arn role i want to assume> --role-session-name dev --serial-number <my arn> --token-code <keyed in token code>
Here you'll get new credentials. Then run the exports again:
export AWS_ACCESS_KEY_ID=<access key>
export AWS_SECRET_ACCESS_KEY=<secret access key>
export AWS_SESSION_TOKEN=<session token>
I hope it helps!
Upvotes: 30
Reputation: 1652
Old post, but might still be useful.
Can you try setting the following in the env and retry:
export AWS_ACCESS_KEY_ID='your access key id here';
export AWS_SECRET_KEY='your secret key here'
Upvotes: 2