3 ms·

I've seen the same issue with instructions for how to configure Keycloak as an OIDC provider - given Keycloak has so many options (some of which might well be s

by g_p 3y ago

I've seen the same issue with instructions for how to configure Keycloak as an OIDC provider - given Keycloak has so many options (some of which might well be security significant), you'd almost want a step by step explicit statement of what every setting should be, to get to a tested, validated and secure configuration. 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.

simonw 3y ago
I've been wanting to setup GitHub Actions to use OIDC with Google Cloud (for deploying to Cloud Run) for a couple of years now, but I find the documentation completely inscrutable: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform https://docs.github.com/en/actions/deployment/security-harde...
- sigwinch28 3y ago
  The gist of it (pun intended) is that GitHub issues GitHub-issued (not issued by your cloud provider!) OIDC tokens to your job runs, and then your job exchanges those tokens for permissions with your cloud provider, which you have configured to trust tokens from GitHub. 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).
  - simonw 3y ago
    For me to follow that procedure I really do need meticulous step-by-step instructions, with a full set of screenshots for every interaction I need to have with any of the web consoles involved. 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.
j33zusjuice 3y ago
Jesus. We fucked with keycloak for like a minute at one of my past jobs where we used FreeIPA. Gave up, and just didn’t use that functionality beyond whatever default stuff it m if it do. IAM is hard. I kind of enjoy it, but there’s always a hundred other things I’m accountable for managing.
- jcadam 3y ago
  What you're supposed to do is have an alcohol-fueled all-night session of modifying values in your Keycloak realm settings one at a time until it works. Then, you export the realm file and tell everyone not to mess with it.
jcadam 3y ago
Enabling devs to do development work on their local machines with Keycloak in the stack is... fun /s.

by g_p 3y ago

simonw 3y ago

I've been wanting to setup GitHub Actions to use OIDC with Google Cloud (for deploying to Cloud Run) for a couple of years now, but I find the documentation completely inscrutable: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform https://docs.github.com/en/actions/deployment/security-harde...

sigwinch28 3y ago
The gist of it (pun intended) is that GitHub issues GitHub-issued (not issued by your cloud provider!) OIDC tokens to your job runs, and then your job exchanges those tokens for permissions with your cloud provider, which you have configured to trust tokens from GitHub. 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).
- simonw 3y ago
  For me to follow that procedure I really do need meticulous step-by-step instructions, with a full set of screenshots for every interaction I need to have with any of the web consoles involved. 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.

j33zusjuice 3y ago

Jesus. We fucked with keycloak for like a minute at one of my past jobs where we used FreeIPA. Gave up, and just didn’t use that functionality beyond whatever default stuff it m if it do. IAM is hard. I kind of enjoy it, but there’s always a hundred other things I’m accountable for managing.

jcadam 3y ago
What you're supposed to do is have an alcohol-fueled all-night session of modifying values in your Keycloak realm settings one at a time until it works. Then, you export the realm file and tell everyone not to mess with it.

jcadam 3y ago

Enabling devs to do development work on their local machines with Keycloak in the stack is... fun /s.