naftulikay / aws-env Goto Github PK

Since we're not using PyPi, see #3, we should update the README so that installation via pip is simple.

Eggs and source distributions for all Python versions we support should be published to PyPI and a signed set of packages should be produced and hosted here on the releases page.

Acceptance Criteria

• Publish source distributions and bdist_egg distributions for
  • Python 2.7
  • Python 3.4
  • Python 3.5
  • Python 3.6?
• Publish GnuPG signed distributions here on the GitHub releases page.

Apparently, as reported by @joshuajlai, if credentials files have quotes surrounding the variable values, it breaks things.

Attempt to fix this either via shlex or some regular expression magic.

Presently with #16, we support lazy-loading of credential files when a qualified profile URI is used. If you have a profile named dev in ~/.aws/credentials.d/92-something.gpg, the profile URI will be dev/92-something; if stg exists in ~/.aws/credentials, then the profile URI will be /stg.

Currently, lazy-loading works for root URIs, but if a non-root profile URI is used, we load all profiles rather than incrementally try to load by the file stem. The most optimal solution would be to lazy load like this:

• ✔️ If passed a root URI:
  1. Load the root credentials file and return profile if found.
  2. Load all credentials and return profile if found.
• 🚫 If passed a non-root URI:
  1. Load files matching the profile URI prefix as a file stem, and return profile if found.
  2. Load all credentials and return profile if found.
• ✔️ If passed a profile name and not a URI, load all files and return profile if found.

Implementing the non-root URI lazy-loading is what is required by this issue.

As reported by @hhercules, there should be an ls functionality for listing available profiles.

Offer tab completions utilizing aws-env --ls to offer completions for which profile to select.

We're still using the old README, which is not relevant anymore. Update the README to reflect the new hauteness.

Since having credentials in plain-text on your filesystem is probably a bad idea, aws-env should attempt to load encrypted files in the following order:

• ~/.aws/credentials.gpg
• ~/.aws/credentials.pgp
• ~/.aws/credentials.asc

It should then attempt to decrypt these files using gpg2 or gpg into memory, and then do the export thing.

Failing finding an encrypted file, it should then default back to the normal ~/.aws/credentials.

AWS Single-Sign-On uses temporary credentials¹, then uses STS to get temporary role credentials².

naftulikay/aws-sso-env already implements the required logic to generate and export role credentials², provided that the temporary credentials¹ are present and not expired.

Temporary credentials¹ are obtained via aws sso login, which opens a browser window to obtain the credentials. Config for SSO is typically stored in ~/.aws/config either as the default profile, or with INI header names like [profile prod]. Rather than storing the access key id and secret access key, the sections look like this:

[profile prod]
sso_start_url = https://$SOMETHING.awsapps.com/start
sso_region = us-east-1
sso_account_id = $ACCOUNT_ID
sso_role_name = $ROLE_NAME
region = us-east-1

Temporary credentials¹ are stored in ~/.aws/sso/cache/$(shasum $SSO_START_URL).json and look like this:

{
  "accessToken": "...",
  "expiresAt": "2021-12-27T20:30:02+0000",
  "region": "us-east-1",
  "startUrl": "SSO_START_URL"
}

Using these credentials, role credentials² can be obtained, and then access is permitted. What is not clear at the moment is the exact logic that aws sso login uses to do the login with the browser window. If this can be determined, then aws-env can do the full lifecycle login, if not, we can only do work if valid, unexpired cached SSO credentials exist.

• Support role credentials generation from cached SSO credentials.
• Support aws sso login functionality to generate temporary credentials¹.