Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
utterances-bot opened this issue May 20, 2024 · 2 comments

Comments

@utterances-bot
Copy link

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/

Copy link

kwlooi commented May 20, 2024

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
Copy link
Owner

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants