Connecting GitHub Actions To AWS Using OIDC

One of StratusGrid's Cloud Infrastructure Leads, Matt Barlow, walks through how to connect GitHub Actions to AWS Using OIDC.
You can find the example code using this link: github.com/mattbarlow-sg/gh-a...

[@scriptkeeper8243]

It's great that John Malkovich is giving tutorials!

[@zimcanit6647]

Great video!

[@nanditasahu2358]

Thanks for the video :)

[@dma98]

Awesome video, quick and step by step perfectly explained. I have one concern though, you hid the arn throughout the whole video, however, it is simple text in the workflow since you've shared the repo. I'm new to this world still, but maybe worth to take it out in a repo secret? Just a suggestion, otherwise love the video

[@GoForthandCloud]

I passed this along to Matt - stay tuned for his response!

[@matthewbarlow9123]

Thank you for the comment! The ARN in the github repo is using a made-up AWS Account ID. AWS Account IDs aren't really sensitive, they are identifying information. When implementing OIDC workflows, I do prefer to put them into a GitHub Action Secret or a GitHub Action Variable, which can be referenced like this in the workflow: 'role-to-assume: ${{ vars.OIDC_ROLE }}'

[@joechung7498]

Great video! would be great if you could add the policies for the roles into the source code too please!

[@jacoboram100]

I followed exactly the same steps but I am unable to run my workflow..Issue is No OpenIDConnect provider found in your account for..could you please confirm if anything else needs as a part of setup

[@subhammisra3631]

Awesome video. I was able to successfully configure and run my composite workflows. But, still stuck with using reusable workflows, in my use case, I want to invoke the reusable workflow which is in an internal repository from any repository in my github organization. Also, the aws assume role action is configured in the reusable workflow, not in caller workflow.

[@matthewbarlow9123]

I think the issue you are describing is that you want to be able to run the workflow from any repository in the org, but the AWS policy specifies the repository. This is indeed an issue with the OIDC implementation, that you can only validate the "sub" claim in the JWT on the AWS side. If all of your repositories were private, then you could use a wildcard and whitelist the entire org. However, if you have a mix of public and private repos this would not be secure. The alternative, which is not a great one, is to whitelist all of your repositories in the policy. If I misunderstood your question, then let me know.

[@adamrusso3871]

I'm trying to follow this, and I got as far as commiting the deploy.yml file when it throws an error: "Run pip install -r requirements.txt Defaulting to user installation because normal site-packages is not writeable ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements.txt' Error: Process completed with exit code 1." Is this a permissions problem or is requirements.txt no longer available?

[@garth-baker-blog]

You covered your IAM role id but it uncovers before you switch pages. I would delete that role if you dont want people fiddling. Great video though! Thank you :)

[@matthewbarlow9123]

The role has indeed been deleted and we will blur that out. Thank you for watching!

[@GoForthandCloud]

Hi Garth, thank you for pointing this out. This issue has been resolved!

[@user-bg4cj3fu4h]

Hi I have tried the exact steps you have shown in video but getting into this below error and suggestions to work on this: Error: User: arn:aws:iam::***:user/jagadish is not authorized to perform: sts:TagSession on resource: arn:aws:iam::***:role/gh-acrtions-role

[@matthewbarlow9123]

When do you get this error, when the github action runs? Also check the spelling of your role "gh-acrtions-role".