joshjohanning / joshjohanning.github.io

josh-ops.com | a devops blog
https://josh-ops.com
MIT License
8 stars 0 forks source link

Using OIDC with Reusable Workflows to Securely Access Cloud Resources | josh-ops #40

Open utterances-bot opened 1 month ago

utterances-bot commented 1 month ago

Using OIDC with Reusable Workflows to Securely Access Cloud Resources | josh-ops

Using Reusable Workflows in GitHub Actions to standardize and security harden your deployment steps

https://josh-ops.com/posts/github-actions-oidc-reusable-workflows/

kwlooi commented 1 month ago

Hello Josh, thanks for sharing this. Very helpful, but I have some doubts. I was able to follow your example and change the sub on my reusable (called) workflow. It all works as described in your post.

However, when I call the reusable workflow from another "caller" client workflow, the sub is not what I expected. The pass in sub identifier is still my caller default OIDC sub claim, not the modified caller sub claim.

Are you also suggesting that we also need to customize the subject in my caller/client repos? I am trying to avoid this because, 1. the callers may have many other workflows that need to use its own identity for some other logic, and 2. I only want my called workflow to have the permissions to use its sub identity to perform some shared services encapsulated in the called workflow.

Appreciate your help. Thanks. Looi

joshjohanning commented 1 month ago

@kwlooi ahh yes, you have to set the sub claim on the caller repo, not the reusable workflow repo. Unfortunately this is how it is for secrets as well - they have to be defined on the caller repository.

You can use the gh-oidc-sub utility to set it for all repos in an organization - but each new repository will need it set (a good case for new repo automation!).

If you're trying to prevent others from using your reusable workflow, you could try tweaking the claims and only trusting certain repositories in the first place on the cloud provider side. Or, you could create your reusable workflow with a bash script to check to see if the${{ github.repository }} variable is from a trusted list.

Otherwise, you could only grant access to the identity behind the OIDC authentication to only have access to the cloud resource if it's using your reusable workflow, I think that could be the same thing?

Good luck and report back if you find a solution to your scenario!