wrdls
commented
5 months ago We hit the same issue when trying to get SSO working with Google Workspace SAML and a separate Dex server (although the same should apply to ArgoCD's Dex server).
We found a workaround which is far from ideal but I thought was worth sharing anyway.
We installed Dex and NGINX alongside Argo Workflows to create a similar setup as ArgoCD.
As an example, Dex would then be reachable on:
- https://argo-workflows.example.com/dex (restricted url)
- http://argo-workflows-nginx/dex (proxied Kubernetes internal url)
- http://argo-workflows-dex:5556 (direct Kubernetes internal url)
The NGINX config would then look something like this:
serverBlock: |-
server {
listen 0.0.0.0:8080;
location /dex/.well-known/openid-configuration {
default_type application/json;
return 200 '{"issuer":"https://argo-workflows.example.com/dex","authorization_endpoint":"https://argo-workflows.example.com/dex/auth","token_endpoint":"http://argo-workflows-nginx/dex/token","jwks_uri":"http://argo-workflows-nginx/dex/keys","userinfo_endpoint":"http://argo-workflows-nginx/dex/userinfo","device_authorization_endpoint":"http://argo-workflows-nginx/dex/device/code","grant_types_supported":["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:device_code"],"response_types_supported":["code"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"code_challenge_methods_supported":["S256","plain"],"scopes_supported":["openid","email","groups","profile","offline_access"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"claims_supported":["iss","sub","aud","iat","exp","email","email_verified","locale","name","preferred_username","at_hash"]}';
}
location /dex {
proxy_pass http://argo-workflows-dex:5556;
}
location / {
proxy_pass http://argo-workflows-server:2746;
}
}So instead of getting /dex/.well-known/openid-configuration from the Dex server, we'll return our own JSON response with the restricted url replaced with the Kubernetes url for the following endpoints:
- token_endpoint
- jwks_uri
- userinfo_endpoint
- device_authorization_endpoint
In our final solution we ended up replacing this static config with a small service that would get the openid-configuration from Dex, replace the urls for the above endpoints and return the modified response. But the idea remains the same.
I'm no expert in SSO, SAML, ... so this might be misguided advice, but hopefully this helps someone else.
Summary
What change needs making? Possibility to handle authentication related communication between Argo Server and ArgoCD's Dex via internal address.
When setting up SSO authentication via ArgoCD's Dex the issuer URL is expected to be accessible via it's external address (a reverse proxy built into argocd-server), while sometimes this is restricted by company network policies.
Introducing the
issuerAliasin v3.2.0 (https://github.com/argoproj/argo-workflows/pull/6831) partially solved the problem helping to bypass the issuer verification, but not completely.The discovery config returned from the
.well-known/openid-configurationendpoint still contain external addresses which breaks the auth flow, after the SSO auth redirects back to the Argo Server's address. The following message is seen in the browser:failed to exchange token: Post "https://{{ArgoCD-external-address}}/api/dex/token": read tcp X.X.X.X:36976->Y.Y.Y.Y:443: read: connection reset by peerX.X.X.X is the argo-server pod's IP Y.Y.Y.Y is the ArgoCD's external IP (pointed by the issuer URL)
ArgoCD itself solves the issue for it's internal authentication via injecting a RoundTripper object to the OIDC client, which rewrites the address and the scheme of the URL before HTTP messages reach the transport layer: https://github.com/argoproj/argo-cd/blob/master/util/oidc/oidc.go#L126-L128
Use Cases
When would you use this?
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.