With Leverage Toolbox >=1.2.0-0.1.1 or >=1.3.5-0.0.2 the SSO login won´t succeed.
Expected Behavior
To be able to SSO login with any Leverage Toolbox version.
Steps to Reproduce
Steps to reproduce the behavior:
Go to a Leverage project
Run leverage aws configure sso
This error is raised: An error occurred (UnauthorizedException) when calling the ListAccounts operation: Session token not found or invalid
Screenshots
╰─ leverage aws configure sso
[16:52:25.685] INFO Required Docker image not found.
[16:52:28.976] INFO Pulling from binbash/leverage-toolbox
[16:54:06.319] INFO Digest: sha256:0d2c38795da6327549f8f377d586c00c95eb0ab8676b4fc3d0d03cf20488f358
[16:54:06.321] INFO Status: Downloaded newer image for binbash/leverage-toolbox:1.3.5-0.0.3
[16:54:06.324] INFO Configuring default profile.
[16:54:08.834] INFO Configuring lo-sso profile.
[19:54:15] INFO Logging in...
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
https://device.sso.us-east-1.amazonaws.com/
Then enter the code:
RNJJ-FDGM
Successfully logged into Start URL: https://leverageops.awsapps.com/start
[19:54:46] INFO Successfully logged in!
[16:54:47.120] INFO Storing account information.
[19:54:47] INFO Clearing profiles
[19:54:47] INFO Getting available accounts and roles
An error occurred (UnauthorizedException) when calling the ListAccounts operation: Session token not found or invalid
Environment (please complete the following information):
Leverage CLI 1.9.2
Additional Context
The problem seems to be in the way the updated AWS CLI stores the SSO cache.
As per the tests, when logging in with a Leverage Toolbox with the new AWS CLI:
So, there is a chance of the find taking the newest file with no token, resulting in an invalid authentication later.
The proposed solution is to replace that find line with something like this:
FILES=$(find "$AWS_SSO_CACHE_DIR" -maxdepth 1 -type f -name '*.json' -not -name 'botocore-client*' -exec ls {} \;)
for file in $FILES;
do
if (jq -r '.accessToken' $file >/dev/null);
then
cp $file "$TOKEN_FILE"
break
fi
done
This was successfully tested locally:
╰─ leverage -v aws configure sso
[17:17:29.525] DEBUG Found config file /home/****/Dev/work/BinBash/code/le-tf-ref-arch-v2-poc/build.env
[17:17:29.534] DEBUG Container configuration:
{
"image": "binbash/leverage-toolbox:1.2.7-localtest",
[17:17:29.842] INFO Configuring default profile.
[17:17:32.492] INFO Configuring lo-sso profile.
[20:17:39] INFO Logging in...
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
https://device.sso.us-east-1.amazonaws.com/
Then enter the code:
KQWP-RTHM
Successfully logged into Start URL: https://***.awsapps.com/start
[20:17:54] INFO Successfully logged in!
[17:17:54.972] INFO Storing account information.
[20:17:55] INFO Clearing profiles
[20:17:55] INFO Getting available accounts and roles
[20:18:04] INFO Configuring lo-sso-security-Administrator.
[20:18:07] INFO Configuring lo-sso-security-DevOps.
[20:18:13] INFO Configuring lo-sso-legacy-DevOps.
[20:18:20] INFO Configuring lo-sso-shared-Administrator.
[20:18:23] INFO Configuring lo-sso-shared-DevOps.
[20:18:30] INFO Configuring lo-sso-management-Administrator.
[20:18:32] INFO Configuring lo-sso-management-DevOps.
[20:18:35] INFO Account profiles written successfully!
Describe the Bug
With Leverage Toolbox
>=1.2.0-0.1.1
or>=1.3.5-0.0.2
the SSO login won´t succeed.Expected Behavior
To be able to SSO login with any Leverage Toolbox version.
Steps to Reproduce
Steps to reproduce the behavior:
leverage aws configure sso
An error occurred (UnauthorizedException) when calling the ListAccounts operation: Session token not found or invalid
Screenshots
Environment (please complete the following information):
Leverage CLI
1.9.2
Additional Context
The problem seems to be in the way the updated AWS CLI stores the SSO cache.
As per the tests, when logging in with a Leverage Toolbox with the new AWS CLI:
With the old AWS CLI:
In the first case one of the files contains the token.
The Leverage Toolbox is renaming the file containing the token for the sake of simplicity, but when two files are found, it seems to be that the newest is the one with no token. This is the command used to rename the file: https://github.com/binbashar/le-docker-leverage-toolbox/blob/06ec755a12e77d3e3b1e0de99debe48f8ee1dfda/scripts/aws-sso/aws-sso-login.sh#L59
So, there is a chance of the find taking the newest file with no token, resulting in an invalid authentication later.
The proposed solution is to replace that
find
line with something like this:This was successfully tested locally: