I'm trying to get a session token in order to set environment variables in order to use a tool which uploads to S3 but doesn't directly support AWS profiles.
aws sts get-session-token --profile myprofile
Enter MFA code for arn:aws:iam::1234567890:mfa/myid:
An error occurred (AccessDenied) when calling the GetSessionToken operation:
Cannot call GetSessionToken with session credentials
Subsequent calls skip the MFA check, indicating that it passed ok.
Running get-session-token without the --profile parameter works fine:
$ aws sts get-session-token
{
"Credentials": {
...
What could be going wrong? Am I even going about this the right way?
The relevant part of my ~/.aws/config:
[profile otherprofile]
mfa_serial=arn:aws:iam::xxx:mfa/myid
aws_access_key_id=xxx
aws_secret_access_key=xxx
[profile myprofile]
source_profile=otherprofile
region=ap-southeast-2
role_arn=arn:aws:iam::xxx:role/owner
mfa_serial=arn:aws:iam::xxx:mfa/myid
Your initial call is using an IAM role. It is attempting to call get-session-token, which will return some temporary credentials.
However, when an IAM Role is used, the AWS CLI automatically uses your normal credentials to call assume-role, thereby receiving back a set of temporary credentials. It is not possible to call get-session-token with temporary credentials (from the role). This is why the error message says Cannot call GetSessionToken with session credentials.
If you wish to call get-session-token, you will need to do it with your normal credentials, as you have done in your second example.
To retrieve the access id, access key and session token from a profile you can use aws configure.
E.g.
aws configure get aws_access_key_id --profile myprofile
aws configure get aws_secret_access_key --profile myprofile
aws configure get aws_session_token --profile myprofile
Related
I am trying to programmatically generate temporary credentials for an assumed role (cross-account) based off of MFA credentials. My ultimate goal is that I only want to have to enter in my MFA token code a single time, and then assume multiple different roles without needing to re-enter my MFA token code (until the MFA session expires).
I am able to obtain temporary MFA credentials no problem:
aws sts get-session-token --serial-number arn:aws-us-gov:iam::<serialnumber>:mfa/<user> --token-code <token code>
I then take the resulting session credentials/token and store it in ~/.aws/credentials
I then want to obtain temporary credentials for an assume role, like the AWS documentation seems to imply is OK:
You cannot call any AWS STS API except AssumeRole or GetCallerIdentity.
However, when I attempt to do so, I get an InvalidClientTokenId error with the following command:
aws sts assume-role --profile default-mfa --role-arn arn:aws-us-gov:iam::<account id>:role/Sandbox_Role --role-session-name clie-access-example --duration 900
I do not have any environment variables set up for AWS credentials (i.e. no AWS_SESSION_TOKEN or AWS_SECRET_ACCESS_KEY environment variables). Also note that I am requesting a token that expires in less than an hour (since as far as I am aware, you cannot request tokens that live longer than an hour with temporary credentials)
Note that if I assume a role implicitly using a profile, everything is fine:
aws sts get-caller-identity --profile role-profile
of for a command that requires actual permissions:
aws dynamodb list-tables --profile role-profile
where my ~/.aws/config file looks like:
[default]
region = us-gov-west-1
output = json
[default-mfa]
region = us-gov-west-1
output = json
[role-profile]
source_profile = default-mfa
region = us-gov-west-1
My AWS user itself does not have any permissions and must assume a role to be able to do anything.
Eventually I will also want to retrieve the assumed role credentials via Postman and store them in my Postman environment so that I can easily switch roles in postman simply by switching environments without needing to copy MFA credentials by hand more than once before the MFA session expires.
I am trying to access an s3 bucket in account A from account B.
I followed this guide Cross-account IAM roles option. Then, to assume the role I use this aws cli command in my code:
aws sts assume-role --role-arn "arn:aws:iam::*********:role/cross-account-s3-access" --role-session-name AWSCLI-Session
I can see that the role was assumed:
{
"Credentials": {
"AccessKeyId": "********",
"SecretAccessKey": "********",
"SessionToken": "********",
"Expiration": "2021-07-29T08:46:33Z"
},
"AssumedRoleUser": {
"AssumedRoleId": "********:AWSCLI-Session",
"Arn": "arn:aws:sts::********:assumed-role/cross-account-s3-access/AWSCLI-Session"
}
}
Then, to check if the cross-account access worked, I perform the following command which return access denied:
+ aws s3 ls s3://digibank-endofday-files-stg
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
My question is what is the --role-session-name flag? I probably put a wrong value but I couldn't find a proper explanation about it. Where do I find value of it??
The flow is:
Using permanent credentials (eg from your IAM User), call AssumeRole() and provide the ARN of the desired role
If you have permission to call AssumeRole on this role, AWS STS will return a set of temporary credentials
You will then need to use those credentials in subsequent calls to AWS services
So, future calls will not be made from your IAM User (since it does not have permission to access S3). Instead, the call will need to be made with the new credentials.
If you were using a programming language, you would use these credentials to make a new Session object and then use it to make API calls.
However, given that you are using the AWS CLI, the easiest method to assume the call is to add a configuration in your ~/.aws/config file similar to this:
[profile prodaccess]
role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
source_profile = default
This configuration is saying: "Use my credentials from the default profile to assume this IAM Role".
You can use it like this:
aws s3 ls s3://digibank-endofday-files-stg --profile prodaccess
For details, see: Switching to an IAM role (AWS CLI) - AWS Identity and Access Management
The AWS CLI will automatically call AssumeRole(), then make the requested call using the temporary credentials that were returned.
I successfully authenticate with 2 factor but when using aws s3 ls I keep getting
An error occurred (InvalidToken) when calling the ListBuckets operation: The provided token is malformed or otherwise invalid.
And I do have admin rights.
Issue was that I wasn't passing the --region in. e.g. aws s3 --region us-gov-west-1 ls. I suppose this could be set with an ENV variable too. That error message is a candidate for improvement.
This error also occurs when aws cli reads the aws_session_token and aws_security_token declared in the ~/.aws file, which might be associated to a previously used account. Removing both and leaving just the key and the credentials associated to the account where the bucket is will force aws to establish the connection.
Please delete .aws/credentials file from your users account and reconfigure your aws cli.
If you already associated with another account then there are high chances of this type of error.
Run aws configure
You may leave access key and access key id blank if you have an IAM role attached
Set value for 'region'
Now you will be able to successfully run 'aws s3 ls'
Else run 'aws s3 ls --region '
If you are using AWS Single Sign-on you can pass --profile <profile_name> and it should solve the issue
In the .aws credentials file remove session token and it will work
I provision an ec2 instance with a specific role. I want to the change the assumed role later form the ec2 cli to gain crross-account access, do something, and then switch back to my original role. How can I achieve this?
I'd use the ~/.aws/config file with the additional profile added.
Assuming that RoleA is your Instance Profile Role,
RoleB is the RoleB is the role you want to assume
RoleA has sts:assumerole
Update your ~/.aws/config to look like the following
[profile roleb]
role_arn = arn:aws:iam::123412341234:role/RoleB
region=us-east-1
credential_source = Ec2InstanceMetadata
So when you want to run the role from the assumed role b you would
aws s3 --profile roleb ls
For more info
https://docs.aws.amazon.com/cli/latest/topic/config-vars.html
You would not switch to another role. Rather, you would request temporary credentials associated with another role, then use those new credentials to make API calls.
The steps would be:
Call aws sts assume-role --role-arn arn:aws:iam::nnn:role/your-role --role-session-name foo
Grab the temporary credentials that are returned. I would recommend storing them in the ~/.aws/credentials file by using aws configure --profile role2
Then make API call with that role, such as: aws s3 ls --profile role2
To use the original credentials, just leave off the --profile.
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?
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!
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.
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.
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
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'
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.
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.
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.
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.
July 2022 Update!
Make sure the target AWS region is enabled. Here is how you can enable a region.
AUGUST 2022 Update!
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
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.
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.