Overwrite the aws config instead of appending

[rdinardi-bw]

We have a workflow in which we need to run this action multiple times to login to multiple aws accounts. On the second run, appending another default profile will cause an error.

Overwriting the aws config instead of just appending to it.

[mrchief]

@rdinardi-bw thanks for reporting this. I think overwriting had it's own issues which I can't remember now. However, instead of limiting ourselves, how about we take profile as an optional input (defaults to default if not provided) and then we write to

echo -e "[profile $INPUT_PROFILE]\noutput = json" >>"$config"

In your steps, you can set AWS_PROFILE=<whatever> and AWS commands will use that profile.

[rdinardi-bw]

@mrchief that sounds like a more robust idea. Will do

[rdinardi-bw]

@mrchief I don't think configuring a profile is as easy as we first thought. Any updates to the AWS config/credentials that's done in entrypoint.sh is only accessible within the docker image for the action itself. The workflow doesn't have access to that.

One possibility could be to do something like this when adding the env vars to the $GITHUB_ENV:

echo "${INPUT_AWS_PROFILE}_AWS_ACCESS_KEY_ID=${aws_access_key_id}" >> $GITHUB_ENV

So you'd end up with a set of env vars for each profile.

Another possibility would be to give examples of how to create a profile in the workflow in a subsequent step. This requires more work on the part of the user however. And creating a file for the config and credentials within the workflow wasn't easy when I tried doing something like this:

aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID --profile default
aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile default

aws configure was failing with permissions issues. I tried manually adding the config/credentials files and still ran into permissions.

This same issue exists in the official AWS actions:
aws-actions/configure-aws-credentials#112

I think it would be okay to switch back to the original solution of overwriting the aws configuration within the action since the config/credentials aren't being exposed to the workflow itself. Let me know what you think.

[mrchief]

I think we may have to do something like

Suggested change

	echo -e "[profile $INPUT_AWS_PROFILE]\noutput = json" >>"$config"
	echo -e "[profile ${INPUT_AWS_PROFILE:-default}]\noutput = json" >>"$config"

but if you have tested it to be working fine, then we're good.

[mrchief]

First of all, excellent PR and I love that you took time to add the docs as well as detailed examples in the docs!

Any updates to the AWS config/credentials that's done in entrypoint.sh is only accessible within the docker image for the action itself.

Yup, this is why we export everything to GITHUB_ENV so the usage becomes something like this

- name: Create First AWS profile
  uses: mrchief/aws-creds-okta@master
  with:
    aws_profile: first-profile
    aws_role_arn: arn:aws:iam::account-id:role/role-name
    okta_username: [email protected]
    okta_password: ${{ secrets.OKTA_PASSWORD }}
    okta_app_url: https://mycompany.okta.com/home/amazon_aws/1234567890abcdefghij/123
    okta_mfa_seed: ${{ secrets.OKTA_MFA_SEED }}

- name: Run AWS Commands as First Profile
  run: |
    aws ec2 describe-instances # runs using AWS_PROFILE=first-profile

- name: Create Second AWS profile
  uses: mrchief/aws-creds-okta@master
  with:
    aws_profile: second-profile
    aws_role_arn: arn:aws:iam::account-id:role/role-name
    okta_username: [email protected]
    okta_password: ${{ secrets.OKTA_PASSWORD }}
    okta_app_url: https://mycompany.okta.com/home/amazon_aws/1234567890abcdefghij/123
    okta_mfa_seed: ${{ secrets.OKTA_MFA_SEED }}

- name: Run AWS Commands as Second Profile
  run: |
    aws ec2 describe-instances # runs using AWS_PROFILE=second-profile

[rdinardi-bw]

ah okay, I see what you're saying now. I'll clean this up and mark it ready for review again. Appreciate you working through this with me.

[rdinardi-bw]

@mrchief Should we be forcing the user to provide an aws_profile? From the example above, it doesn't really make a difference what the profile name is.

This goes back to what we were talking about earlier. Since we can't really configure the awscli to use profiles and are just passing back the access key, secret key and session token, it seems to me like we should just overwrite the configuration file each time.

There's no real benefit to keeping all the profiles in the config if we aren't able to switch profiles.

[mrchief]

There's no real benefit to keeping all the profiles in the config if we aren't able to switch profiles.

Actually, you're right. So... we did all this work for nothing? 😄

[rdinardi-bw]

Actually, you're right. So... we did all this work for nothing? 😄

I think I learned some things, so there may have been some benefit 😆

I'm going to switch it back to overwriting the configuration and I'll mark the pr ready to review!

[rdinardi-bw]

@mrchief any chance you can take another look at this?

[mrchief]

Mostly a readme update, right? If so, I think we should also add a blurb saying how to go about creating multiple profiles and basically summarize the conversation in this thread (including the possible workaround).

On a related note, I found this https://github.community/t/docker-container-action-how-to-persist-files-in-workspace/18441 so there may be a way to persist the profile if we saved the file to /home/runner/work/_temp/_github_home. Maybe worth a try?