allow OIDC instead of keys

[exussum12]

Github supports open id connect to get credentials from AWS, This repo rejects anything which does not pass though the AWS creds.

Could OIDC support be added?

[forensicmike]

@exussum12 thought id let you know that i decided to fork this to see if I could get it working. after gutting a few things, it seems to work by simply removing the parameters. note: i do not recommend pointing to my fork, but you could always do the same until the real one is fixed :)

forensicmike@911f19b

[chetan]

Looks good and thanks for experimenting and confirming it works @forensicmike. I'll try to get it implemented as an option soon.

[forensicmike]

I did a bit more experimenting and wanted to share what I found about how the aws-actions/configure-aws-credentials@v1 action works, which is the recommended way to implement the OIDC connectivity.

it appears that after successfully completing, every step afterwards on that same job will automatically include the following (it shows up in the action runner output):

    AWS_DEFAULT_REGION: ca-central-1
    AWS_REGION: ca-central-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_SESSION_TOKEN: ***```

[exussum12]

@forensicmike yeah I ended up just writing a simple script when I couldn't find a preexisting action

https://github.com/SykesCottages/technology-blog/blob/master/.github/workflows/deploy.yml#L30

Probably needed some docs adding too about adding

permissions:
      id-token: write
      contents: read

Thanks for looking!

[chetan]

Great, thanks. Will definitely be easier to leverage that action to set things up.

[forensicmike]

Yeah, that caught me as well. Also think there needs to be a bit more more fanfare around the need to manually setup the trust policy in AWS lest any repo on Github can assume that role if they possess the role ARN..

[johnmcase]

@chetan Sorry to revive such and old issue, but why is this marked as completed?

If I'm understanding correctly, this action will still fail if the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY inputs are not supplied:

invalidate-cloudfront-action/entrypoint.sh

Line 19 in c384d5f

if [ -z "$AWS_ACCESS_KEY_ID" ]; then

The fork @forensicmike made removed the checks for those parameters and presumed that the caller had already called the aws-actions/configure-aws-credentials action prior to calling this one.

What am I missing?

[chetan]

@johnmcase successfully running the aws-actions/configure-aws-credentials action passes those variables to this action, as documented in the readme.

If you're seeing an issue than you may need to look into the output of that action to see what's going on. You can refer to the readme in this repo and the test action for some more examples.