SSO: allow issuer (and redirectUrl) to be sourced from a Secret like clientId/clientSecret

Summary

Allow sso.issuer (and sso.redirectUrl) in workflow-controller-configmap to be sourced from a Secret, the way sso.clientId and sso.clientSecret already are, instead of only as a literal string.

Today (config/sso.go, v4.1.4):

Issuer       string                  `json:"issuer"`
RedirectURL  string                  `json:"redirectUrl"`
ClientID     apiv1.SecretKeySelector `json:"clientId"`
ClientSecret apiv1.SecretKeySelector `json:"clientSecret"`

server/auth/sso/sso.go resolves the two SecretKeySelectors from Kubernetes and passes c.Issuer to oidc.NewProvider verbatim; config/controller.go parseConfigMap is a plain yaml.UnmarshalStrict with no environment expansion or reference resolution. So the issuer has exactly one source: a literal in the ConfigMap.

Proposal, either of:

1. Accept a SecretKeySelector for issuer and redirectUrl (keeping the plain string form for compatibility), for example:

   yaml复制

   sso: |
     issuerFrom:
       name: argo-workflows-sso
       key: issuer
     clientId:
       name: argo-workflows-sso
       key: clientID
     clientSecret:
       name: argo-workflows-sso
       key: clientSecret

2. Or support Argo CD's $<secret-name>:<key> substitution for string fields of the sso block.

Use Cases

The OIDC issuer is not static configuration in every deployment: OIDC operators (Dex's, for example) register a client and write the issuer, client ID and client secret together into one Secret. The client ID and secret can already be consumed from that Secret; the issuer cannot, so the operator-written value sits unread next to a hand-maintained copy in the ConfigMap. When Argo Workflows is installed on many clusters from one template, each cluster's issuer has to be derived by convention and rendered into the ConfigMap per cluster, and a divergence only shows as oidc: id token issued by a different provider at login time.

The sibling Argo projects already treat the issuer as a value that comes from somewhere else:

• Argo CD resolves $<secret>:<key> references anywhere in argocd-cm's oidc.config, so issuer: $argocd-sso:issuer reads the operator-written Secret at runtime (https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sensitive-data-and-sso-client-secrets).
• Kargo takes OIDC_ISSUER_URL (with the client IDs) through environment variables, so the chart can feed it with valueFrom.secretKeyRef from the same Secret as the client secret.

Argo Workflows is the one component of the family where the issuer can only be a literal, which is why it ends up templated per cluster while every other field of the SSO configuration is a reference.

Message from the maintainers:

Love this feature request? Give it a . We prioritise the proposals with the most .