3.1.1: unconditionally fetch credentials during ecr subcommand setup

Unconditionally fetch credentials during ECR command setup to make sure we have the full compliment of SAML or OIDC data before making calls to the AWS API.

Fixes an issue where errors stating failed to sign request: failed to retrieve credentials were happening when using profiles configured with external identity providers when attempting to login to an ECR endpoint.

3.1.0

Support ECR authentication directly in aws-runas. Instead of some convoluted command pipeline using aws-runas, awscli, and docker login, aws-runas now handles ECR authentication directly in the tool via the aws-runas ecr login subcommand.

Read more about how to use this feature at the doc site

3.0.3

Before checking SAML roles, be certain that we have a SAML assertion.

Fixes #63

3.0.2

Fix process hang when using aws-runas to execute a command using assume role credential duration longer than 1 hour.

Fixes: #60 and #61

3.0.1

Fix a few bugs:

• Fix the EC2 IMDSv2 response to work with client programs using the Golang AWS SDK (#58)
• Fix file handling bug when managing cache (credential and cookie) files on Windows. (#59)

3.0.0

Version 3.0 is a ground-up rewrite (including documentation) with a number of behind the scenes updates and quite a few new features

• Added support for Web Identity credentials in addition to SAML credentials. As of this version, aws-runas supports ALL mechanisms for using the AWS Assume Role API (and AFAIK, is the only tool out there to do so)
• The ECS metadata credential service is now feature-comparable to the EC2 metadata credential service, meaning that either service can be managed using the browser interface and/or the HTTP API
• The ECS metadata credential service allows dynamic profile credential fetching when a profile name gets appended to the service endpoint URL path (doc link)
• The EC2 metadata credential service supports using a custom port, which permits the service to run without root/admin privileges. Running using the "traditional" 169.254.169.254 address is still supported, but will always require elevated privileges for configuring the IP address on a network interface, and running on a privileged port.
• The EC2 metadata credential service now supports the IMDSv2 token path, and still handles IMDSv1
• Use a baked-in SSM session client to remove the requirement to install the AWS ssm session plugin, a CLI option is provided if use of the plugin is necessary or desired. (doc link)
• Add support for SSH over SSM sessions in the build-in client, and via the plugin (doc link)
• More coherent and expansive use of subcommands in the CLI to make separation of the various functions in the tool clearer. (doc link)
• Smarter command completion functionality for bash and zsh users. Linux RPM and DEB packages automatically install the auto-complete script to a system-wide location. (doc link)
• Integration/functional tests now include testing SAML and Web Identity functionality with external public IdPs (currently Okta and Onelogin)
• Support Apple M1 based systems
• Enable configuration to specify the type of MFA to use with external identity providers, overriding the auto detection logic
• AzureAD SAML client support. (doc link)

2.3.2

Add feature to allow user selection of mfa type.

When configured for SAML authentication, allow user to specify the mfa type to use. This will override the "auto"
MFA processing logic in the external provider and only use the requested type. Behavior is undefined if the
requested type is not available for the account (expect an error at the very least, and possibly a panic)

Configuration can be specified using the mfa_type config file attribute, the -t command line option, or the
MFA_TYPE environment variable. Standard precedence rules apply.

Values of code and push should be supported by all providers (except Keycloak, which only allows code/totp MFA).
Providers may support other values, and would be documented in the provider-specific documentation.

2.3.1

Fix an issue where role data parsing for SAML clients returns the AWS saml provider integration ARN instead of the role ARN. This would cause an issue where running aws-runas -l reports the roles as

arn:aws:iam::1234567890:saml-provider/ProviderName

instead of

arn:aws:iam::1234567890:role/TheRole

Add --ecs flag

Add the --ecs flag to create an endpoint on the local system which can be used to get credentials for a profile.

Unlike the EC2 metadata feature (the --ec2 flag), this new ECS feature does not require sudo/admin privileges on the host to run, since it uses an existing network interface (localhost), and a high-numbered port. However, the AWS libraries do not automatically know this endpoint address (like it does with the hard-coded http://169.254.169.254/ endpoint for the EC2 metadata service), so you are required to set the AWS_CONTAINER_CREDENTIALS_FULL_URI environment variable for the programs you are running to use this endpoint.

Use the right credentials when using SSM features

Make sure we're using the right set of credentials when doing SSM target resolution, so the API calls are using the roles in the correct accounts when using jump roles.