Which flow and service/grant etc seems to matter a lot, and be a good example where you'd want a very clear playbook of step by step instructions that you can hand off to someone else to unambiguously follow.
Which flow and service/grant etc seems to matter a lot, and be a good example where you'd want a very clear playbook of step by step instructions that you can hand off to someone else to unambiguously follow.
From experience, OIDC authentication to cloud providers from GitHub actions boils down to:
1. Get your GitHub actions workflow to be able to work with its own (GitHub) tokens by configuring workflow permissions.
2. Configure your cloud provider to verify tokens issued by GitHub actions OIDC server thingymabob (technical term).
3. Configure your cloud provider to grant permissions in that cloud provider (or issue its own tokens with those permissions) based on certain values in the verified GitHub tokens that is presented with. If your cloud provider trusts GitHub, then it can treat the values in the token (workflow name, branch run from, owner and name of GitHub repo) as trusted.
4. Use a GitHub action from your cloud provider to do the negotiation with your cloud provider when your job runs, performing the exchange configured in (3).
If I ever get up enough courage to do this myself I'll take and publish those screenshots, but I'll probably continue to drag my heels for a few more years.