Struggling with hopping between thousands of AWS Accounts and assuming millions of roles on your CLI? Is storing and managing credentials a headache for you? Don’t worry… I have got your back! Just follow me till the end :)
Managing programmatic access to AWS has always been troublesome. I have been in this situation quite a lot, and that forced me to look out for ways to simplify my life so that I can focus more on getting things done quicker, without the hassle of remembering Account IDs, AWS Role names, and a whole lot of other things. Phew!
Without any fancy intro, let’s get right into it.
Let me walk you through some approaches to authenticating and gaining access to AWS resources programmatically or from the AWS CLI.
Note: The following approaches expects that you already have access to SSO authentication within IAM Identity Center, for yourself to be able to use it. You should ideally have met these prerequisites.
In short, you should be able to see the following screen:
You can access this page using the SSO start URL, which usually appears like https://d-1a2bc34de5.awsapps.com/start/.
Special Tip: You can customize the SSO Start URL as well to something of your choice very easily, simply by following this.
This changeshttps://d-1a2bc34de5.awsapps.com/start/→https://mysso-myway.awsapps.com/start/. This is extremely helpful, as it is often hard to remember these similar looking URLs, especially when you have multiple such SSO URLs. :)
Approach #1: Exporting Environment Variables
The very first and foremost approach, which is quite a common way is to export the temporary credentials as environment variables. This method is especially useful for temporary access, and scripting.
Steps:
[1] Obtain Temporary Credentials (Access Keys) for the account and role, from the AWS Access Portal:
[2] Export the copied credentials as environment variables, in your terminal:
export AWS_ACCESS_KEY_ID=<YourAccessKeyId>
export AWS_SECRET_ACCESS_KEY=<YourSecretAccessKey>
export AWS_SESSION_TOKEN=<YourSessionToken>
You can confirm the allowed access by running the command:
$ aws sts get-caller-identity
{
"UserId": "ABCD1234EFGH5678IJKL9:ibatulanand+test+@gmail.com",
"Account": "111111111111",
"Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_personal_a12b345cde6fg789/ibatulanand+test+@gmail.com"
}
My take on this approach:
It’s easy-peasy to gain access and switching accounts only requires copying and exporting environment variables of other accounts. This is what most of the people I have heard of use because of its simplicity, and effectiveness mainly for temporary access or development purposes.
But, as I mentioned, it is effective for temporary use only. Moreover, the credentials are exposed in the environment as well, which isn’t the best.
Approach #2: Configuring AWS-provided Wizard
1. Using “aws configure sso” wizard
This solution is particularly native to AWS, as it provides profile management through the aws configure sso wizard and this method is quite user-friendly for setting up multiple profiles.
Steps:
[1] Run the configuration wizard and provide the following information:
$ aws configure sso
SSO session name (Recommended): mysso
SSO start URL [None]: https://mysso-myway.awsapps.com/start/
SSO region [None]: ap-northeast-1
SSO registration scopes [None]: sso:account:access
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.ap-northeast-1.amazonaws.com/
Then enter the code:
FTXD-TLBW
... ...
... ...
There are 5 AWS accounts available to you.
Using the account ID 111111111111
The only role available to you is: personal
Using the role name "personal"
CLI default client Region [ap-northeast-1]:
CLI default output format [None]:
CLI profile name [personal]:
To use this profile, specify the profile name using --profile, as shown:
aws s3 ls --profile personal
You can verify the access by running:
aws sts get-caller-identity --profile personal
{
"UserId": "ABCD1234EFGH5678IJKL9:atul-test@gmail.com",
"Account": "111111111111",
"Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_personal_a12b345cde6fg789/atul-test@gmail.com"
}
You can also confirm this by checking the ~/.aws/config file:
$ cat ~/.aws/config
[default]
region = ap-northeast-1
[profile personal]
sso_session = mysso
sso_account_id = 111111111111
sso_role_name = personal
region = ap-northeast-1
My take on this approach:
It definitely is a better and sort of long-term solution, as compared to the first approach. And, it simplifies the setup process and integrates seamlessly with AWS SSO.
But, the wizard itself has limited capabilities and may require a lot of effort in case you have multiple accounts and roles. Also, you would need to create as many different profiles for each combination.
2. Using “aws configure sso-session” wizard
This is the new addition to the approaches by AWS, and as per AWS, it is not compatible with the legacy IAM Identity Center.
Following a similar procedure as the aws configure sso, you will be able to create an sso-session in the ~/.aws/config file, which will look something like this:
$ cat ~/.aws/config
[default]
region = ap-northeast-1
[profile personal]
sso_session = mysso
sso_account_id = 111111111111
sso_role_name = personal
region = ap-northeast-1
[sso-session mysso]
sso_start_url = https://mysso-myway.awsapps.com/start/
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
The real benefit of this method is that it allows sso-session configurations to be reused across multiple profiles, like dev, pre-prod, prod, or any profile categorization you may have.
My take on this approach:
This approach sounds most promising so far, as it offers advanced configuration options, and fine-grained control over sessions. Also, these wizard bases approaches allow to retrieve and cache a set of credentials by running these commands:
“$ aws sso login — profile personal” OR “$ aws sso login — sso-session mysso”
But, it still is complex to setup and requires additional management in the future.
Approach #3: Using the “aws-sso-cli” utility tool
Now comes the one I was waiting to tell you all about!
This approach enhances the experience with a simple, yet powerful, utility tool that provides so much convenience and flexibility. This tool is an absolute game-changer, making the whole process of switching accounts and assuming roles incredibly smooth.
I can’t emphasize enough how much aws-sso-cli has improved my workflow, especially because it offers a streamlined and intuitive interface.
Steps:
[1] Install the aws-sso-cli utility tool following the official documentation, or if you’re on Mac, you can simply install it using Homebrew using the command:
brew install aws-sso-cli
[2] Run the following command to do the basic configuration:
aws-sso
This will allow us to set permission up like this:
And, after the configuration is done, it shows:
$ aws-sso
Verify this code in your browser: XTRD-XZBM
List of AWS roles for SSO Instance: Default [Expires in: 6h 2m]
AccountIdPad | AccountAlias | RoleName | Profile | Expires
=======================================================================================================
111111111111 | Atul Anand | personal | 111111111111:personal | Expired
222222222222 | xxx-xxxxx-xxxxx | admin | 222222222222:admin | Expired
333333333333 | yyy-yyyyy-yyyyy | admin | 333333333333:admin | Expired
444444444444 | zzz-zzzzz-zzzzz | developer | 444444444444:developer | Expired
555555555555 | test | developer | 555555555555:developer | Expired
You can even enable Auto-completion using the command:
aws-sso completions -I
Read more about auto-completion here.
To switch accounts, simply run the command (with tabs to auto-complete):
aws-sso-profile 111111111111:personal
And, finally, confirm the access by running the same command as before:
aws sts get-caller-identity
{
"UserId": "ABCD1234EFGH5678IJKL9:atul-test@gmail.com",
"Account": "111111111111",
"Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_personal_a12b345cde6fg789/atul-test@gmail.com"
}
There are a lot of other features available with this tool. So, if you are interested in knowing and trying out more, refer to these:
My take on this approach:
This is the most intuitive, easy-to-setup, and full of features approach that really elevates the experience of working with multiple AWS accounts and roles.
The only thing is that it’s a third party open-source tool, which might be a concern for a few people, but not the majority.
If you are also willing to try, have already tried aws-sso-cli, or know of any other alternatives, please let me know and share with other fellow AWS buddies.
This article was originally published on Medium.
Top comments (1)
Nicely detailed article!