Read AWS credentials from disk (#14382)

[lefth]

Description

Other programs can read the AWS key and secret from ~/.aws/credentials
(or other configuration file), and with this change Algo can as well.

Optional environment variables: AWS_PROFILE, AWS_SHARED_CREDENTIALS_FILE

The file is not read if the credentials are already set as an Ansible
variable or an environment variable.

Motivation and Context

Setting the credentials on the command line or as an environment variable is an unnecessary annoyance when the credentials are already configured in the official AWS way (like you would have after running aws configure). And the security implications are debatable, but if I already have the credentials in a config file, I don't want them in my shell history or my shell initialization.

Issue here: #14382

How Has This Been Tested?

With AWS, I ran the main playbook:

 ansible-playbook main.yml -e "provider=ec2
                                server_name=algo
                                ondemand_cellular=false
                                ondemand_wifi=false
                                dns_adblocking=true
                                ssh_tunneling=true
                                store_pki=false
                                region=us-east-1
                                do_token=token"

I tested the following config file situations:

• with a configuration file set properly
• with a missing configuration file
• with a configuration file with no section header
• with a custom section header (and AWS_PROFILE set)
• with wrong data in the config file but correct data set as environment variables (this worked)

Errors that came up did not stop execution unless the authentication info was wrong. The "Deploy the template" task often failed during my testing, but this is an unrelated issue--the playbook can only get to that stage if the authentication info is okay.

I also added a test script that is more limited, but does some of the above checks.

Types of changes

• Bug fix (non-breaking change which fixes an issue). I consider this a bugfix because the credentials file is standard and it's unusual that Algo doesn't read it.
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly. This is a core AWS feature, I don't think we need to document it.
• I have added tests to cover my changes.
• All new and existing tests passed. The existing tests seem unrelated. Is the test procedure documented, or can we skip it?

[CLAassistant]

All committers have signed the CLA.

[cageyv]

We could use https://github.com/99designs/aws-vault instead of files
Store AWS secrets inside ~/.aws/credentials is not secure way
Also there is post about this issue: https://cageyv.dev/posts/aws-vault/

[glennschler]

I do not use ~/.aws/credentials for security reason. I like ansible vault. I think it is already installed with the ansible requirements of Algo, or it is a small extra step

mkdir vars
SECURE_VIM=Y ansible-vault create vars/aws-secrets.vault.yml
SECURE_VIM=Y ansible-vault edit vars/aws-secrets.vault.yml

e.g. aws-secrets.vault.yml

aws_access_key: ...
aws_secret_key: ...

The command

./algo --ask-vault-pass -e @vars/aws-secrets.vault.yml -e '{provider: ec2,
  ondemand_cellular: false,
  ondemand_wifi: false,
  dns_adblocking: false,
  ssh_tunneling: false,
  store_pki: false }' -e server_name=algo-$(date +%Y%b%d-%H%M)

[dguido]

Thank you for this contribution! This is a valuable feature that aligns with standard AWS practices.

After reviewing the implementation, we've identified several improvements needed:

1. Variable naming inconsistency (aws_access_key vs access_key)
2. Missing session token support for temporary credentials
3. Debug statements that should be removed
4. Better error handling for missing/malformed files

Rather than requesting multiple changes on this PR, we'll create a new PR that incorporates your work along with these fixes. We'll make sure to credit you for the original implementation.

Closing this in favor of the upcoming PR. Thank you again for identifying this need and providing the initial implementation!