Direct OIDC ID token JWT support

[iainlane]

Summary

It's not possible to use any old OIDC token to authenticate with an Argo Workflows server to use RBAC. You're either in client mode, in which case you need a service account token. Or you're in SSO mode, in which case the ID token needs to have been issued by Argo Workflows itself: it needs to be signed by an internal private key.

I've set up Dex, I've got it issuing ID tokens exchanged from GitHub's ID tokens, but I've fallen at this hurdle - it doesn't seem possible to get Argo WF to accept those tokens at all.

Use Cases

I want to use GitHub Actions OIDC to submit Argo Workflows from GitHub Actions Workflows (GHA). (I imagine other OIDC providers would work similarly but this is the one I'm interested in right now.)

Design

Here's a high-level sketch of a design for how it could work:

1. In the config, under sso, specify an issuer and an audience.
2. When we see a JWT inside the Authorization header, we verify it as normal by checking the signature, expiry and all of the standard claims. Additionally, we would verify the issuer and the audience are what was supplied in the config.
3. After this it looks mostly like SSO looks now. We look at the same annotations on the same service accounts and see if any rbac-rule annotations match against the JWT's claims.
   1. Ideally all claims from the JWT are provided to the expression's context.

That doesn't sound too intrusive to me. What do you think?

If agreed I'd be happy to work on this change.

---

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

[danielshiplett]

This sounds like a great use case to me. I'm also facing a similar need as I am building a product that is (trying to) integrate Argo Workflows into a larger system. We use Keycloak as our SSO. I am able to successfully use the Keycloak generated user JWT from my central OAuth2 resource server that coordinates the entire system with all of our other components. I cannot do this with Argo Workflows. This leaves us at a point where we need to use shared service accounts, which is less than ideal from a system management and security perspective.

[agilgur5]

For reference, copying over from https://github.com/argoproj/argo-workflows/issues/12992#issuecomment-2110519468:

That seems to date back to #4095 and seems to have been on purpose [...]

Looking further, Argo having its own JWE apparently stems from #4035 / #4027 / #3873 et al. Instead of implementing refresh tokens in that PR, it was decided to use a new JWE effectively as a token exchange. Although it's not entirely clear why that was decided.

I might be missing something, but that would suggest that #12049 [(this issue)] was the original approach and then was changed?

and https://github.com/argoproj/argo-workflows/issues/12992#issuecomment-2111675118:

Otherwise I agree that directly using the provider tokens would seem to make more sense (and have less indirection and therefore less room for error), and some SIG Security folks agreed (albeit only based on a short summary) during a meeting today as well.

[...]

I'd like to make sure we have full context on that decision before changing that. Off-hand, I can imagine the JWE could be useful for some providers that don't support refresh tokens or have other limitations, but I would imagine that the vast majority are capable, and that Dex as an intermediary could mitigate various limitations too (if needed, similar to its current optional usage in Workflows). May check with some Intuit folks if they can find records of it etc

Notably, ID tokens cannot be refreshed (unlike access tokens), so they have a limited expiry set by the provider. I'm thinking that maybe we support both depending on the configuration, then can choose between "direct" usage for more compat and Argo's exchanged tokens for more customization/configurability of the token. Or have a way to do something similar to the latter through Dex