I can use the same authentication configuration across commands run within the generation commands and those in the automation commands
Current Behaviour
The generation commands have a setCredentials setup which relies on user defined config profiles to determine how they authenticate with a given AWS acccount
The automation commands have a setCredentials setup which uses environment variables to assume roles into the accounts and save the resulting session keys under the default AWS_ACCESS_KEY_ID/SECRET_KEY. Support for user defined profiles for automation commands has been added in https://github.com/hamlet-io/executor-bash/pull/244
Possible Solution
Extend the environment variable based approach in the automation provider to use profiles as their configuration source and add support for defining the profiles that hamlet uses through the provided env vars
The AWS_AUTOMATION_USER env var would be extended to support different base auth process and essentially become the HAMLET_AWS_AUTH_SOURCE which would permit the following values
INSTANCE - uses the instance or ecs task role as the base source of authentication ( we would detect the role type as part of the process )
INSTANCE:EC2 - would force the use of the ec2 instance role
INSTANCE:ECS - would force the use of the ECS instance role
ENV - uses the standard environment variables AWS_ACCESS_KEY_ID/SECRET_KEY as the base
USER - uses the existing AWS_AUTOMATION_USER prefixed AWS_ACCESS_KEY/SECRET KEYS
CONFIG - uses the existing aws config file or the file specified in AWS_CONFIG_FILE
When using ROLE,ENV or USER a new config file would be created within HAMLET_HOME_DIR/.aws/config and the AWS_CONFIG_FILE variable would be updated to use that file
ROLE would align with the credential_source profile option
ENV would align with the credential_source profile option and the Environment value
USER would create a new base profile in the config and subsequent profiles would use this profile as its source_profile
The HAMLET_AWS_AUTH_SOURCE would also support the standard Account ID overrides to handle different accounts using different processes
So HAMLET_MYACCT1_AWS_AUTH_SOURCE would override the source for the account MYACCT1
Context
This provides a standardised way of handing AWS authentication that supports different methods and allows us to automate configuration approach that works locally or across different automation providers in a standard way
Expected Behaviour
I can use the same authentication configuration across commands run within the generation commands and those in the automation commands
Current Behaviour
Possible Solution
Extend the environment variable based approach in the automation provider to use profiles as their configuration source and add support for defining the profiles that hamlet uses through the provided env vars
The AWS_AUTOMATION_USER env var would be extended to support different base auth process and essentially become the HAMLET_AWS_AUTH_SOURCE which would permit the following values
When using ROLE,ENV or USER a new config file would be created within HAMLET_HOME_DIR/.aws/config and the AWS_CONFIG_FILE variable would be updated to use that file
Each time setCredentials.sh is called the config file will be updated ( https://docs.aws.amazon.com/cli/latest/reference/configure/set.html ) with the appropriate profile to align with the configuration option.
The different sources would align with the configuration in https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html
ROLE would align with the
credential_sourceprofile option ENV would align with thecredential_sourceprofile option and theEnvironmentvalue USER would create a new base profile in the config and subsequent profiles would use this profile as its source_profileThe HAMLET_AWS_AUTH_SOURCE would also support the standard Account ID overrides to handle different accounts using different processes
So HAMLET_MYACCT1_AWS_AUTH_SOURCE would override the source for the account MYACCT1
Context
This provides a standardised way of handing AWS authentication that supports different methods and allows us to automate configuration approach that works locally or across different automation providers in a standard way