Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

AWS SSO CLI Helpers

Content of the .aws files

  • config: Contain the config for all the profiles and sso-session. It only contains non-sensitive data.
  • credentials: Contains credentials for AWS accounts. Keys in case of key auth, and SSO session tokens in case of SSO authentication
  • cache: Stores temporary credentials (e.g. sso session tokens). Used to avoid re-authentication each time we use CLI
  • cli: contains cache and history for CLI.

Profile sections use [profile profile_name] (e.g., [profile user1]; note the "profile" prefix, which distinguishes it from the credentials file).

credential_process = /opt/home/theodo/.local/bin/go-aws-sso assume -q -a 381491832352 -n Admin. This can be used in credentials file to use a command to get the credentials.

All these are overridden by these env variables:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
AWS_DEFAULT_REGION
AWS_PROFILE
AWS_CONFIG_FILE
AWS_SHARED_CREDENTIALS_FILE

What happens when I run aws configure sso

  • config: contains [profile profile-name] and [sso-session session-name]
  • sso/cache: contains files with cached tokens.
  • I need to learn about SSO in general to understand the different fields
  • credentials is never changes since SSO uses refresheable tokens.

AWS SSO Helpers

go-aws-sso:

How it works

This has 3 sub-commands:

  • generate: creates a config file in XDG_CONFIG.
  • assume: takes an account_id and role_name and assume it.
  • refresh: Refreshes the credentials. Nothing happens if the credentials are still not expired

If the command is invoked without subcommands it fetches an interactive menu with all the accounts and roles to choose from.

There are 2 sets of files created:

  • config file: generate with config and contains the SSO instance url and the region.
  • credentials: it has the regions and uses a credentials_process helper that points to go-aws-sso assume. The later fetches the SSO access token then uses it to GetRoleCredentials for the specified role.
credential_process = /opt/home/theodo/.local/bin/go-aws-sso assume -q -a 339712704276 -n ReadOnly
  • sso/cache folder: it contains two files access-token.json which contain SSO credentials and last-usage which contains metadata about the currently (or latest) used profile.

Deal breaker

The tool is simple and minimalist, but it does not work for a complex setup. It is like a tool to connect to whatever profile (account+role) we need, fast. It support one SSO instance at a time and one profile at a time. In addition to that, it does drift a lot from the default aws cli behavior.

  1. It creates its own SSO cached credentials with its own format. and adds a new file last-usage.json
  2. It does not rely on .aws/config file.
  3. It creates a default .aws/credentials and point to assume which generates temporary credentials.
  4. [Not Sure] The credentials are not cached anywhere which means the assume is called every time.

Pros

  • It works
  • Simple to use.
  • Single Go binary
  • Can run in headless mode (outputs the url instead of opening a new browser tab)

Cons

  • Supports only one SSO instance
  • Does not configure environment variables.
  • Does not adhere to the AWS SSO philosophy.
  • Weird and kind of opinionated! It uses the credentials file with sso authentication. And it creates files and configs in the format specified by them. -> The tool uses the AWS SSO API to fetch temporary credentials (Access Key ID, Secret Access Key, Session Token) for the chosen role. Then it either uses credential_process which configures go-aws-sso to be the credentials provider. Or persist which write a short lived credentials (keys) into the credentials file.

ssosync

This is awslabs tools which populates AWS SSO from G Suite

aws-vault

Manager for AWS credentials. It stores the creds in the machine keystore (e.g. pass) and when it is invoked it uses the STS to generate temporary credentials via the GetSessionToken or AssumeRole API calls.

Then it injects the temporary credentials into the process when aws-vault exec. Key Difference: SSO commands are SSO-centric (federated access, no stored IAM keys needed), while aws-vault is credential-vault-centric (stores IAM keys securely and creates temporary sessions). SSO is for identity federation; aws-vault is for credential isolation.

It does not match the use case.

awsesh

This is fairly new, written in Go as a TUI. It is almost the same as go-aws-sso, since it also uses sso API to generate temporary credentials and store them in credentials.

How it works

It authenticate to SSO instance and then it creates the following files:

  • awesesh: contains the information about the SSO instance. And the account used.
  • awesesh-account: contains all the accounts and associated roles. It may be used for caching purposes.
  • awsesh-tokens: contains the tokens for the SSO instance
  • credentials: contains static credentials generates when logging in to the account/role in awsesh.

Deal breaker

Although this is more beautiful, it is almost the same as go-aws-sso. It is not for complex setup but it is intended for daily use. It simplifies switching but not configuration oriented. Also it is opinionated and uses it own conventions compared to native aws sso cli. It has the same drawbacks as go-aws-sso but it uses static credentials which is supported by go-aws-sso.

Pros

  • TUI
  • Simple to use
  • Single Go Binary
  • Supports many SSO Orgs

Cons

  • No Documentation
  • New and kind of vibecoded
  • Opinionated and does not rely on the aws config file conventions themselves.
  • Support one profile (support for multiple profiles has been added).

yawsso

This seems not maintained (latest release in 2024). This is same as go-aws-cli. It syncs SSO to regular AWS credentials.

:point_down_tone4::point_down_tone4: Generated by AI :point_down_tone4::point_down_tone4:

yawsso works by:

  1. Reading AWS config profiles – It parses your ~/.aws/config file to identify which profiles are using SSO (with sso_start_url, sso_region, sso_account_id, sso_role_name).
  2. Extracting cached SSO session – It finds the corresponding session in the ~/.aws/sso/cache/ files created by aws sso login.
  3. Calling AWS SSO OIDC APIs (via boto3/AWS SDK) – With that cached SSO access token, yawsso requests temporary AWS credentials (access key, secret, session token) for the given account and role, just like the CLI would internally.
  4. Writing credentials to legacy store – It then writes those credentials into the legacy ~/.aws/credentials file under the selected or mapped profile names (e.g., dev, prod, or foo if you rename).
  5. Optional extras – It can also export them into environment variables (-e), copy them to the clipboard, or refresh them automatically when expired (auto).

:point_up_2_tone4::point_up_2_tone4: Generated by AI :point_up_2_tone4::point_up_2_tone4:

aws-sso-util

How it works

It connects to the SSO instances and pull all the profiles to .config file. Then it logs in once to the SSO instance. And when a profile is used by aws CLI, it uses SSO API to get credentials.

The behavior is the closest you can get to the native SSO CLI.

Pros

  • Use the same features as the native aws sso cli
  • Manages .config file instead of adding new files
  • Login once and switch between the accounts
  • Simple to use.
  • It adds an credential-helper in config file for AWS SDKs that don't support SSO.
  • It has a lib

Cons

  • configure command does not support the latest .aws/config format to infer sso information form the it.
  • configure does not take the information from the CLI directly. In fact it does support providing the SSO fields through environment variables, inference through aws config file, or with command line option. (-u and --sso-region)
  • Loose support for multiple SSO instances. If 2 instances have the same account the second configure overrides the first.

aws-sso-cli

Powerfull aws-sso tool, intended to replace aws cli altogether.

How it works

The aws-sso-cli differs so much from the vanilla aws cli. It relies on a yaml file in XDG_CONFIG_HOME. The config is generated by setup command and contains the SSO instance configuration as well as the cli configuration. It also creates other files:

  • config.yaml: see above
  • cache.json: contains cached roles (with accounts and aliases)
  • secure/: a Folder with encrypted credentials.

Deal Breaker

Simple put: It is too complex for me + it is so opinionated.

  • It is very powerful and offers a lot of features and options but it has its own way to do things. As for me, I really want to me as minimalist as possible and rely on vanilla tools or tools that follows the standards from AWS tooling.
  • It has so much to learn, and offers a lot of NON-STANDARD ways to do things (mainly assume roles or connect to profiles). Although it can be configured to follow aws cli v2 standards, I don't think it is worth it at least at the stage I am on right now. Maybe in the future, my workflow will get so much complex and will require using something like this tool.

Pros

  • Powerful
  • Very good documentation
  • Feature rich
  • Supports encryption for credentials

Cons

  • Complex
  • So opinionated! Although it replaces aws cli v2 entirely and comes with it own philosophy and interface.

AWSume: AWS Assume Made Awesome! | AWSume

This is more to replace aws assume role.

References