Feature Request (w/ PoC implementation): Allow users to specify environment variables as part of an AWS profile

[Daniel J. Rollins]

Thank you for the great tool!

On practically every project I've worked on, there has always been a need to specify one or more environment variables which may or may not change based on which profile we are using. For example. my terminal history is filled with commands like:

AWS_ENVIRONMENT=TESTING BUILD_TYPE=Debug aws-vault exec qa cdk deploy

This approach involves editing multiple parts of the command line when we want to run the command using a different profile. I inevitably forget to do this multiple times a day!

It would be great if we could specify some additional environment variables in the profile sections within the ~/.aws/config file, which are then added the the environment as part of the exec sub command, for example:

$ cat ~/.aws/config
[profile qa]
sso_region = eu-west-1
sso_account_id = ...
sso_role_name = ...
sso_start_url = ...
env_vars =
 AWS_ENVIRONMENT=TESTING
 BUILD_TYPE=Debug

$ aws-vault exec qa env
...
AWS_VAULT=qa
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
AWS_SESSION_TOKEN=...
AWS_SESSION_EXPIRATION=2022-05-17T01:59:51Z
AWS_ENVIRONMENT=TESTING
BUILD_TYPE=Debug

I have implemented a proof of concept in my fork here, which seems to work well so far: djrollins/aws-vault@99designs:master...master

I'd be happy to work on it some more and raise a PR if this is something that would be useful for the project.

Cheers

[Jan Gazda]

I do not think this is a feature I'd want from aws-vault the main reasons are

• possibility to leak secrets which is the exact opposite aws-vault is trying to achieve - for this very reason .aws/credentials exists, to separate the concerns
• .aws/config is already cluttered enough - I have 50+ profiles there.

Instead take a look at:

• chamber
• direnv with combination of dotenv instead

[Daniel J. Rollins]

Apologies if I wasn't clear on the use-case for this feature request. I wasn't suggesting this should be used for secrets - only for other configuration environment variables that may change based on the AWS profile selected.

Chamber looks great, but it feels a little overkill for configuration values that aren't secrets. From the docs it looks like we'd still need to remember to switch to the correct chamber for an AWS profile before running a command within that profile. This still leaves two things to keep in-sync, which is what I was hoping to avoid.

I have used direnv and dotenv before, and whilst these are great for ensuring per-project env vars are set, it doesn't solve the problem of setting different env vars within a project based on the AWS profile selected.

With that in mind, I still believe this could be a worthwhile addition to the aws-vault project.

I can understand the the issue with clogging up the .aws/config, however this was just my first stab at a design. We could instead externalise the environment variables in separate file. This file could then be automatically discovered based on the profile name (e.g. .aws/env/<profile-name>) or directly referenced with an env_file= entry in the profile.

EDIT: On the other had, if we externalise the env vars to an auto-discoverable file, then this could be done by a third-party tool that looks up the file based on the "AWS_VAULT" environment variable... 🤔.

[Michael Tibben]

Hey @djrollins, I'm a fan of the unix philosophy of "do one thing well" and composable tools. aws-vault will use the environment available in your shell. So it sounds to me like a simple shell wrapper would work well for your use-case. Feel free to create a shell alias / function and add to the contrib directory.

For example aws-vault-env PROFILE ... could load load .aws/env/PROFILE and then execute aws-vault exec PROFILE ...