It will not be what you assume…
I had a script the place I go in an MFA token and assume a task. It’s working completely.
I attempted to create one other script the very same means and I’m getting this error:
An error occurred (InvalidClientTokenId) when calling the AssumeRole operation: The safety token included within the request is invalid
I discovered this publish and it’s all of the stuff you would anticipate:
You should go in a sound token-code with the MFA code for the serial quantity you’re utilizing in your sts assume-role name. Be certain your serial quantity, exterior ID, and code variables are set the way in which you assume they’re (If you’re utilizing an exterior id).
You should set your AWS credentials prior to creating your assume-role name as a result of the decision wants credentials with permissions to execute the command and assume the function.
I knew I used to be setting these values the identical means I used to be within the different script so what was the issue?
Lastly, I seen the next. In a single script I had the next on the very prime of the script earlier than I set the session variable referenced beneath:
export AWS_ACCESS_KEY_ID=$aws_access_key_id
export AWS_SECRET_ACCESS_KEY=$aws_secret_access_key
export AWS_SESSION_TOKEN=$session
export AWS_REGION=$aws_region
Within the subsequent script, I set the worth of the session variable prior to creating the above name like this as a result of I used to be utilizing that variable to set the session title in my CLI command. Then I inadvertently set the AWS_SESSION_TOKEN to my session title upfront of calling my assume function command. Oops.
session="MYSESSION"
export AWS_ACCESS_KEY_ID=$aws_access_key_id
export AWS_SECRET_ACCESS_KEY=$aws_secret_access_key
export AWS_SESSION_TOKEN=$session
export AWS_REGION=$aws_region
I moved session=”MYSESSION” beneath the export instructions and it labored.
Why???
In regards to the AWS Session Token
I believe maybe the AWS ClientTokenId, Session Token and Safety Token are the identical factor referenced within the documentation beneath however I’m unsure.
Repair: Documentation, implementation, and error messages ought to use constant terminology.
You’ll be able to see an instance output of the session token right here and it’s what you get after calling assume-role with MFA:
After you name the AWS assume-role command from the CLI with MFA you’ll get again some JSON that features a session token. That’s the session token you set right here, by retrieving the JSON values and setting them appropriately beneath.
export AWS_ACCESS_KEY_ID=$aws_access_key_id
export AWS_SECRET_ACCESS_KEY=$aws_secret_access_key
export AWS_SESSION_TOKEN=$aws_session_token
export AWS_REGION=$aws_region
Setting the AWS_SESSION_TOKEN was overriding my present session token that’s used to authenticate actions on AWS so was inflicting subsequent actions to fail resulting from invalid credentials.
The AWS_SESSION_TOKEN is to not be confused with the token-code handed into the AWS assume-role command and it isn’t the identical because the role-session-name, which is what I incorrectly used to overwrite the AWS_SESSION_TOKEN.
assume-role
--role-arn <worth>
--role-session-name <worth>
[--policy-arns <value>]
[--policy <value>]
[--duration-seconds <value>]
[--tags <value>]
[--transitive-tag-keys <value>]
[--external-id <value>]
[--serial-number <value>]
[--token-code <value>]
[--cli-input-json | --cli-input-yaml]
[--generate-cli-skeleton <value>]
[--cli-auto-prompt <value>]
Invalid MFA Token
In the event you go in an invalid MFA token to the above command you’ll get this error:
An error occurred (AccessDenied) when calling the AssumeRole operation: MultiFactorAuthentication failed with invalid MFA one time go code.
Unset Variables When Achieved Utilizing the Position
After you might be completed utilizing the session ensure to unset your variables or it could trigger issues the subsequent time you attempt to assume the function.
Unset AWS_SECRET_ACCESS_KEY AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
Further Double Quotes
There’s one different challenge I discussed a number of instances on this weblog associated to different errors. Once you retrieve the values from JSON be sure to don’t have further double quotes round your variable. It could be very nice if this was simply dealt with for you or if a extra acceptable error message was thrown.
You’ll be able to take away the additional double quotes utilizing sed.
json=$(aws sts assume-role --role-arn $assumerole --serial-number $serialno --token-code $code --external-id $externalid --role-session-name $sessionname)id=$(echo $json | jq '.Credentials.AccessKeyId' | sed 's/"//g')
key=$(echo $json | jq '.Credentials.SecretAccessKey' | sed 's/"//g')
st=$(echo $json | jq '.Credentials.SessionToken' | sed 's/"//g')export AWS_ACCESS_KEY_ID=$id
export AWS_SECRET_ACCESS_KEY=$key
export AWS_SESSION_TOKEN=$st
Teri Radichel — Comply with me @teriradichel on Twitter
© 2nd Sight Lab 2022
____________________________________________
About this weblog:
Wish to be taught extra about Cybersecurity and Cloud Safety? Try: Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety courses, articles, white papers, shows, and podcasts
