v3.3.0 and oidc secret warning

[llavaud]

Describe the bug

Since version 3.3.0, the application-controller and server spam logs with the following warning:

{"level":"warning","msg":"config referenced '$oidc.jumpcloud.clientSecret', but key does not exist in secret","time":"2026-02-05T07:46:48Z"}
{"level":"warning","msg":"config referenced '$oidc.jumpcloud.clientSecret', but key does not exist in secret","time":"2026-02-05T07:46:58Z"}
{"level":"warning","msg":"config referenced '$oidc.jumpcloud.clientSecret', but key does not exist in secret","time":"2026-02-05T07:47:08Z"}

secret is present and SSO login works as expected.

• argocd-cm

apiVersion: v1
data:
  oidc.config: |
    name: JumpCloud
    issuer: https://oauth.id.jumpcloud.com/
    clientID: REDACTED
    cliClientID: REDACTED
    clientSecret: $oidc.jumpcloud.clientSecret
    requestedIDTokenClaims:
      email:
        essential: true
      groups:
        essential: true
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argo-cd

• argocd-secret

apiVersion: v1
data:
  admin.password: REDACTED
  admin.passwordMtime: REDACTED
  oidc.jumpcloud.clientSecret: REDACTED
  server.secretkey: REDACTED
  webhook.github.secret: REDACTED
kind: Secret
metadata:
  name: argocd-secret
  namespace: argo-cd
type: Opaque

Version

argocd: v3.3.0
  BuildDate: 2026-02-02T07:28:36Z
  GitCommit: fd6b7d5b3cba5e7aa7ad400b0fb905a81018a77b
  GitTreeState: clean
  GitTag: v3.3.0
  GoVersion: go1.25.5
  Compiler: gc
  Platform: linux/amd64

[ChristianCiach]

Hopefully fixed by

• fix(server): OIDC config via secrets fails (#18269) #26214

I am eagerly awaiting the next patch release :)

[Nenodema]

We are running into the same issue and wanted to add an important clarification.

In our case this is not just a misleading error message. When the OIDC client secret is stored in a Secret outside of argocd-secret, Argo CD is unable to resolve it and authentication actually fails.

What we observed:

• Referencing the clientSecret via $<secret-name>:<key> only works when the value is placed in argocd-secret.
• When using a dedicated Secret (for example argocd-oidc-secret) with the recommended label app.kubernetes.io/part-of: argocd, Argo CD logs that the key does not exist and does not load the secret.
• As a result, OIDC login breaks completely rather than producing a harmless warning.

This suggests the problem is not limited to logging but affects secret resolution at runtime.

Can you confirm whether referencing external secrets is still supported, or if something changed in v3.3.0 regarding which secrets are watched by the settings controller?

[rouke-broersma]

@Nenodema I don't see what you're describing. I have the log warnings described in the issue but I can still login with oidc so login is not actually broken for me.

[Nenodema]

Thanks for checking!

Interesting that OIDC still works for you. In our environment the behavior is different and it actually breaks authentication.

To clarify what we are seeing:

• When the client secret is stored in argocd-secret, OIDC works immediately.
• When we move the same value to a separate Secret (for example argocd-oidc-secret) and reference it via $secret-name:key, Argo CD logs that the key does not exist and the server behaves as if no client secret is configured.
• The login flow redirects to the IdP, but the callback fails because the client authentication cannot be completed.

So for us it is not just a cosmetic warning, it directly impacts the login flow.

A few things that might explain the difference between our setups:

• We are running v3.3.0.
• The external Secret is in the same namespace and has the app.kubernetes.io/part-of: argocd label.
• Restarting argocd-server did not change the behavior.

Could it be that only argocd-secret is currently being watched by the settings controller? That would explain why some setups appear to work while others do not.

[rouke-broersma]

@Nenodema I am on v3.3.0 otherwise I would not reply to an issue that appeared in v3.3.0. I am using an external secret otherwise I wouldn't reply that I'm not seeing the same behavior as you. See: https://github.com/broersma-forslund/homelab/blob/main/apps/cluster/argocd/values.yaml

[Nenodema]

@rouke-broersma
No need to be grumpy 🙂 You were right. My mistake, I should have read more carefully.

We will take another look at our configuration to see what might be causing the different behavior.

Sharing our sanitized configuration for reference:

argocd-cm.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  url: https://argocd.example.com
  oidc.config: |
    name: AzureAD
    issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
    clientID: <client-id>
    clientSecret: $argocd-oidc-secret:oidc.azuread.clientSecret
    requestedIDTokenClaims:
      groups:
        essential: true
    requestedScopes:
      - openid
      - profile
      - email
      - offline_access

argocd-oidc-secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: argocd-oidc-secret
  labels:
    app.kubernetes.io/part-of: argocd
type: Opaque
stringData:
  oidc.azuread.clientSecret: <redacted>

errors \\edit: I made a mistake while redacting my logs earlier, the message failed to load OIDC configuration does not occur in our logs.

{"level":"warning","msg":"config referenced '$oidc.azuread.clientSecret', but key does not exist in secret","time":"2026-02-05T14:44:59Z"}

Output from the cluster showing the key does exist in the secret:

$ kubectl get secret argocd-oidc-secret -n argocd -o json | jq '.data'
{
  "oidc.azuread.clientSecret": "<redacted-base64>"
}

[rouke-broersma]

I don't have the failed to load OIDC configuration error, only the key does not exist in secret warning. One difference I see is that my keys are not 'nested'. Perhaps that makes a difference?

[Nenodema]

Good point! In our tests, storing the client secret outside argocd-secret triggers the warning and breaks OIDC, while moving the exact same key/value into argocd-secret immediately fixes it. So it seems unlikely that the key structure is the cause?

What about this PR, it seems to be related (also mntioned above).

[maciejmaz]

I have the exact same issue on Argocd v3.2.6.

[nneul]

I've been beating my head against the wall on this issue as well on 3.3.0, until I realized "It's working fine." - it's just complaining about something that is there.

In my case, I'm pre-creating the argocd-secret so that I can have "all necessary components for the provisioning of argocd" fully ready and can deploy in a single operation, instead of having to bring it up and then adjust/patch afterwards - or encode the secrets in the produced helm chart. Actual config is working fine, it's just spewing the warnings twice every thirty seconds it looks like.

argo-cd-argocd-server-859cd8f5d6-m7n9n:server time="2026-02-19T21:56:53Z" level=warning msg="config referenced '$oidc.azure.clientSecret', but key does not exist in secret"
argo-cd-argocd-server-859cd8f5d6-m7n9n:server time="2026-02-19T21:56:53Z" level=warning msg="config referenced '$oidc.azure.issuer', but key does not exist in secret"
argo-cd-argocd-application-controller-0:application-controller time="2026-02-19T21:56:58Z" level=warning msg="config referenced '$oidc.azure.clientID', but key does not exist in secret"
argo-cd-argocd-application-controller-0:application-controller time="2026-02-19T21:56:58Z" level=warning msg="config referenced '$oidc.azure.clientSecret', but key does not exist in secret"
argo-cd-argocd-application-controller-0:application-controller time="2026-02-19T21:56:58Z" level=warning msg="config referenced '$oidc.azure.issuer', but key does not exist in secret"
argo-cd-argocd-server-859cd8f5d6-7twlt:server time="2026-02-19T21:57:00Z" level=warning msg="config referenced '$oidc.azure.clientID', but key does not exist in secret"
argo-cd-argocd-server-859cd8f5d6-7twlt:server time="2026-02-19T21:57:00Z" level=warning msg="config referenced '$oidc.azure.clientSecret', but key does not exist in secret"
argo-cd-argocd-server-859cd8f5d6-7twlt:server time="2026-02-19T21:57:00Z" level=warning msg="config referenced '$oidc.azure.issuer', but key does not exist in secret"

(And yes, I know that issuer and clientid are not secrets, it's more consistent for my config to have those values coming from the same location instead of splitting the elements apart.)

[ilbarone87]

Fixed for me on 3.3.1