You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
In the config, under sso, specify an issuer and an audience.
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.
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.
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 👍.
The text was updated successfully, but these errors were encountered:
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.
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:
sso
, specify an issuer and an audience.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.rbac-rule
annotations match against the JWT's claims.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 👍.
The text was updated successfully, but these errors were encountered: