Describe the feature

This is attempting to drive closure to existing feature requests/PRs by proposing the exact feature set we should support for exporting credentials. This proposes an aws configure export-creds command that resolves the existing AWS CLI credential chain and formats the credentials in various formats, including as environment variables and in the credential process format, allowing the AWS CLI to be used as a credential process.

Use Case

For context, original issue:

• Provide way to get current credentials
• Current PR with partial implementation: Adding the option to export AWS credentials with a command #6808

To save you a few clicks, the rationale for this feature:

• While we strive for parity across our tools, there are times when the AWS CLI might support certain credential providers before other tools. Customers would like the ability to leverage the credential resolution process of the CLI in other SDKs and tools.
• Even with credential provider parity, there may be differences in implementations and configurations across tools. A common one that comes up, and is referenced in the linked issue, is that the CLI by default uses file based caching for credentials, where often times in SDKs you need to provide your own caching provider and explicitly provide the type of cache you want. Customers want a way want to reuse the existing caching mechanism/defaults in place in the CLI without having to configure each individual tool.
• Customers may sometimes need to interact with frameworks, tools, or services that only support a subset of credential providers, the most common one being environment variables. Customers would like the ability to export credentials in these formats, e.g. environment variables, to interop with other tools.
• There are several third party tools that provide this, or similar, functionality, but this is a crucial/core enough feature that we really should be providing a "built-in" mechanism that customers can utilize.
• This also gives you an easy way to consolidate all your credential related configuration in a single profile that you can use across multiple profiles. Admittedly, you can see this as a workaround for supporting "profile inheritance/mixins" in the config file (which has come up in various issues throughout the years), and I see that we've provided credential provider specific solutions to this (I see botocore has an sso_session section it supports), but it still provides a succinct way to reduce duplication in your AWS config file.

Proposed Solution

I propose we move forward with #6808 with a few additional changes.

• We will add an aws configure export-creds command that will use the AWS CLI's credential resolution process and output the results in various formats.
• The command will support a --format parameter that supports common formats the customers use for exporting credentials.
• The command will support outputting credentials in the output required by the credential process feature. This enables the AWS CLI to be used as a credential process.

Synopsis

aws configure export credentials [--format process|env|powershell|windows-cmd]

The default value will be process which outputs the credentials in the output required by a credential process.
We'll support the following output formats, which are the formats we see with SSO, or other console related tooling that allows you to export creds in various formats:

• process - The default output format, enables usage as a credential_process source.
• env - Exports env vars as in a posix compatible shell (export AWS_ACCESS_KEY_ID=...)
• powershell - Export env vars in powershell specific format ($Env:AWS_ACCESS_KEY_ID="...")
• windows-cmd - Export env vars in a windows cmd console format (set AWS_ACCESS_KEY_ID=...)

Examples

To use this command as a credential process in your config file:

[profile my-sso-config]
#  All the relevant sso config

[profile dev]
region = us-west-2
# Other non-cred related configuration
credential_process = aws configure export-creds --profile my-sso-config

[profile staging]
region = us-west-2
# Other non-cred related config for staging
credential_process = aws configure export-creds --profile my-sso-config

Then use just like any other profile:

$ aws s3 ls --profile dev
$ aws s3 ls --profile staging

To use this with env vars in a posix shell (bash/zsh etc):

$ eval $(aws configure export-creds --profile dev)
$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************ABCD              env       # <----- Using the sourced env vars
secret_key     ****************EFGH              env       # <----- Using the sourced env vars
    region                us-west-2      config-file    ~/.aws/config

I noticed we have a few tools that also export fish shell creds, not sure if it's worth supporting at the moment so I've omitted it for now, but additional formatters would be straightforward to add. Also not supporting the "CLI config" format because if you're going to write out a new profile/section to the CLI config file, we should be recommending them to use a credential_process instead, which can properly handle (non-trivial) refreshes.

Other Information

One of the implementation details we'll need to figure out is being able to provide the expiry time of credentials, which is required by the credential process (if you want to refresh credentials), and arguably should be supported by other formats as well (e.g. env vars). For the AWS CLI, and specifically botocore, we do not provide the expiry time as a public attribute.

FWIW, I don't think I had any specific reason for not exposing the expiry time other than it was an implementation detail that wasn't relevant to consumers of credentials (I don't remember the exact timeline but I know we added assume role / refreshable credentials years before I introduced the credential process functionality). We really only cared about expiry time to handle the bookkeeping for advisory/mandatory refreshes.

I've seen the discussion on boto/botocore#2694, and while I think it is curious about the "not expired but maybe actually it is" expiry time specific to IMDS, I will follow up and see if there's any path forward there. Maybe we just add it to ReadOnlyCredentials with an extra attribute denoting expiry time fuzziness is sufficient.

Other implementation note we'll need to be careful of is detecting recursive invocations when running CLI commands against profiles that also have the AWS CLI configured as a credential process. We'll probably need to require you specify a different profile than the parent CLI process otherwise we'll error out, but we can explore what options we have available to us.

Last thing, I'm happy to drive this to completion and implement the remaining delta we need to get this feature complete.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CLI version used

v2

Environment details (OS name and version, etc.)

All of them