Provide a way for `assume_role_with_web_identity` to not set `AWS_*` environment variables in `BASH_ENV`

[blimmer]

Provide a way for `assume_role_with_web_identity` to not set `AWS_*` environment variables in `BASH_ENV`

[brivu]

Hey @blimmer,

Thanks for opening this issue. I've been going back and forth how to handle the assume_role_with_web_identity command so I'm glad we have an opportunity to learn more.

As of today, the assume_role_with_web_identity command only generates new temporary keys and gets exported to $BASH_ENV. It does not tie the keys to a specific profile, which has been causing some confusion.

However In the setup command, if there is a role_arn, the assume_role_with_web_identity command is run. Once the keys are generated, they are passed through the configure.sh script, which ties the keys to a specific profile by running the cli's aws configure set commands. That's the only reason why the keys and session token are stored as environment variables.

The intent with the assume_role_with_web_identity was always to tie the generated keys to a profile so I've been considering removing the command and just consolidating it into the setup command (similarl to the the configure script)

With your suggestion, if we use configure_aws_environment_variables: false, the assume_role_with_web_identity command will essentially do nothing other than generating keys. They won't be tied to any profile nor be exported as environment variables.

In your use case above, are you able to run the aws-cli/setup command twice (once for each profile)? That way, you can have a profile for your build process and one for your deploy process. When you run your build and deploy processes, you can tie the appropriate profile to each command.

Let me know if I am missing anything!
Brian

[blimmer]

Hi @brivu, thanks for the quick and detailed response!

In my use case, yep, I was calling aws-cli/setup twice. This appropriately configured the profiles, but it still left the AWS_* environment variables in the $BASH_ENV. I think I could have explicitly overridden the downstream consumer (a legacy Javascript tool that uses aws-sdk@2) to specify a profile and ignore the environment variables but, by default, it was using the environment variables, not the default profile.

I worked around the problem like this:

- run: touch $BASH_ENV && cp $BASH_ENV "$BASH_ENV.bak"
- aws-cli/setup:
    profile_name: codeartifact
    role_arn: << parameters.readonly_iam_role >>
    configure_default_region: false
    configure_profile_region: true
    region: us-west-2
- run: mv "$BASH_ENV.bak" "$BASH_ENV"
- run: codeartifact get-authorization-token --profile codeartifact

However, it would be nice if I could somehow specify to the orb, "just create the profile, don't mess with my environment".

[brivu]

Hey @blimmer,

Thanks for the clarification, it makes a lot of sense now. You're workaround is pretty slick!

In terms of a solution for the orb, the config.sh script uses the values stored in environment variables to create profiles located in the ~/.aws/credentials file by running the commands below:

aws configure set aws_access_key_id \
    "$AWS_CLI_STR_ACCESS_KEY_ID" \
    --profile "$AWS_CLI_STR_PROFILE_NAME"

aws configure set aws_secret_access_key \
    "$AWS_CLI_STR_SECRET_ACCESS_KEY" \
    --profile "$AWS_CLI_STR_PROFILE_NAME"

if [ -n "${AWS_SESSION_TOKEN}" ]; then
    aws configure set aws_session_token \
        "${AWS_SESSION_TOKEN}" \
        --profile "$AWS_CLI_STR_PROFILE_NAME"
fi

I am thinking that we could possibly append this script with unset so that you won't run into this issue.

unset AWS_SESSION_TOKEN
unset AWS_ACCESS_KEY
unset AWS_ACCESS_KEY_ID

That way, once the profiles are configured, the environment variables will be unset. Let me know if that'll work. In the meantime, I'll huddle up with my team and see what we can do.

Thanks!
Brian

[blimmer]

I don't think an unset will remove those env variables from $BASH_ENV, only the active shell. So the next step that runs will re-source $BASH_ENV and you'll have the same problem.

Two ideas:

1. Could the configure script accept the variables as input (e.g., configure.sh --key-id="hardcoded" --secret-key="hardcoded" --security-token="hardcoded")?
2. Could you write off the keys to a separate file (e.g., mktemp -t aws-profile-codeartifact-XXXXXX)?