feature: Argo CD: pull OIDC clientID and issuer from existing secret

[jessebot]

Is your feature request related to a problem?

Right now we have to specify the oidc issuer and clientID directly in plain text via the values.yaml when applying the argo-cd helm chart. It's possible to specify a clientSecret in another secret, but not the clientID or issuer. This information is still considered private, so it'd be good to have this obscured.

Related helm chart

argo-cd

Describe the solution you'd like

I'd like to see the issuer and clientID also optionally called from an existing secret, in the same way that we can specify a clientSecret in another secret, example currently:

    oidc.config: |
      name: provider
      issuer: https://my.domain/realms/coolrealm
      clientID: argocd
      clientSecret: $argocd-provider:oidc.provider.clientSecret
      requestedScopes: ["openid", "profile", "email", "groups"]
      requestedIDTokenClaims: {"groups": {"essential": true}}

Proposed update:

    oidc.config: |
      name: provider
      issuer: $argocd-provider:oidc.provider.issuer
      clientID: $argocd-provider:oidc.provider.clientID
      clientSecret: $argocd-provider:oidc.provider.clientSecret
      requestedScopes: ["openid", "profile", "email", "groups"]
      requestedIDTokenClaims: {"groups": {"essential": true}}

Describe alternatives you've considered

An alternative would be to just allow for an existingSecret for OIDC credentials where issuer, clientID, and clientSecret are all defined keys.

Additional context

This would make everything a bit more secure and allow for more open sourcing of Argo CD configurations without exposing any useful information for attackers.

[mkilchhofer]

Did you test your proposed solution already? If its not yet implemented inside the code, you have to file a feature request in the upstream project repo over there:
https://github.com/argoproj/argo-cd

[jessebot]

@michaelvl I did not! Sorry about that. Should I close this one or wait till the other one is responded to in the other repo? :)

[mkilchhofer]

Should I close this one (..)?

We can leave it open, it doesn't matter 👍

[github-actions]

This issue 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.