fix(argo-cd): Use ingress crt for dex when enabled

[ShimiTaNaka]

Fixes: #2171

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• My build is green (troubleshooting builds).

[ShimiTaNaka]

I'm not quite sure why the chart testing fails, would love to some help, seems unrelated to my change :)

[tico24]

It's failing at exactly the point you've changed, so I'd argue it's related to your change :)

templates/argocd-server/deployment.yaml: unable to parse YAML: error converting YAML to JSON: yaml: line 336: mapping values are not allowed in this context

[ShimiTaNaka]

ok, so it's line 336 after rendering, because the chart itself change is in line 426 :)
Checking

[mkilchhofer]

I am not sure if this is needed. Dex is controlled by a binary which is copied into the dex container. I thought that this utility does generate some TLS config between argo-cd-server and dex. And dex is exposed via a reverse proxy component inside argo-cd-server

By default, argocd-dex-server generates a non-persistent, self signed certificate to use for its HTTPS endpoint on startup.
Source: https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/#configuring-tls-to-argocd-dex-server

Also we should be aware of the reload "issue":

Please note, that as opposed to argocd-server, the argocd-dex-server is not able to pick up changes to this secret automatically. If you create (or update) this secret, the argocd-dex-server pods need to be restarted.
Source: https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/#inbound-tls-certificates-used-by-argocd-dex-server

[ShimiTaNaka]

It actually is
specifically when setting up OKTA.
The change doesn't require anything on the dex itself actually and dex isn't even configured with SSL https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml#L994C12-L994C12
Instead, we configure ingress for argocd-server.
During the login, argocd-server makes an API endpoint to:
https://ui.argocd.yourorganization.net/api/dex/.well-known/openid-configuration
and then there is an SSL issue.
I can't reproduce it on a working environment, seems that the CA is cached, but it's shown in the server logs:
Initializing OIDC provider (issuer: https://ui.argocd.yourorganization.net/api/dex)"
(obviously with our private URL) and there was an SSL error, it was fixed once we changed the secret name in question

[ShimiTaNaka]

Important to mention, this does not create a certificate for DEX, rather, if we create an ingress to ArgoCD server, with a certificate, map it.

[ShimiTaNaka]

I think I've found a better solution
I'll check it out first

[ShimiTaNaka]

Current implementation inspired by argoproj/argo-cd#7572 (comment)

I also hope it makes the incentive clearer :)

[mkilchhofer]

I can still not follow your issue.
For ingress traffic from outside kubernetes to dex (user callbacks), the path chain is:

Ingress -> argocd-server (acts as a proxy) -> dex

For outgoing traffic from dex to the upstream IdP, traffic flows directly:

Dex -> IdP

Did you test your proposal (eg. with kubectl edit)?
Also the current implementation of this PR can be achieved by setting:

server:
  volumeMounts:
    - mountPath: /etc/ssl/certs/ingress-ca-certificates.crt
      name: ingress-ca-certificate
      subPath: ca.crt
  volumes:
    - name: ingress-ca-certificate
      secret:
        secretName: my-secret
        optional: true
        items:
          - key: ca.crt
            path: ca.crt

[ShimiTaNaka]

I have tested it
and I know it can be achieved by it, it's just makes things simpler.
The login flow is as follows:

1. User goes to https://argocd.domain.suffix and clicks "Sign in with Okta"
2. Argo-server sends him to ssoUrl (As specified in https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/okta/)
3. User logs in, and gets a redirect to https://argocd.domain.suffix/api/dex/callback
4. User gets authenticated with a session (for https://argocd.domain.suffix site) and gets 303 redirect to https://argocd.domain.suffix
5. argo-server makes API call to https://argocd.domain.suffix/api/dex/.well-known/openid-configuration to validate the session cookie signature

The last part fails because argo-server communicates with the dex via external call all the way with the ingress and not internally, so when the ingress is using self signed CA, the call fails.

As you've mentioned, this can be also achieved by passing the values you've provided, the PR as it is just makes it easier on the user

I will try to reproduce and get back to you on it

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.