Ability to utilize secret value to populate Dex clientSecret

[Kampe]

Is there a way to utilize a secret to populate the value for clientSecret within the dex config options? There doesn't seem to be a way to include environment variables on a per component basis?

[iam-veeramalla]

Hi @Kampe Thanks for raising issue with us.

Can you please provide more information on what exactly you are trying to achieve and steps to reproduce.

[Kampe]

Sure!

Currently, this is the config we can use to set up our client for DEX:

      dex:
        config: |
          connectors:
            - type: github
              id: github
              name: GitHub
              config:
                redirectURI: https://localhost:8080/api/dex/callback
                clientID: 85409387507sd67f6
                clientSecret: $dex.github.clientSecret
                orgs:
                - name: org-name

However, I can't use my own secret to populate these values, in a perfect world both clientID and clientSecret can be set via environment variables within the DEX configuration block. This would be wildly useful to everyone to have available. Currently you are able to configure this through bolting on secrets to the argocd built ins, so ideally they are not attached to the $dex.github object and can be accessed via their very own secrets, seeing as you'd probably not want to touch argocd internal secrets to get at your own personal environment level variables.

[iam-veeramalla]

Hi @Kampe , You can also use your own kubernetes secrets.

clientSecret: $dex.github.clientSecret # Alternatively $<some_K8S_secret>:dex.github.clientSecret

Is this what you are looking for ?

[brandon-piner-aruba]

@iam-veeramalla please can you elaborate on this because the documentation still seems to be missing information.

I have created a secret in the same namespace as argocd.

apiVersion: v1
kind: Secret
metadata:
  name: argocd-github-secret
  namespace: argocd
data:
  clientSecret: 1ce6dfe5134cd281831b2ab648e9caf5e3d36027
type: Opaque

Then what should the config be?

data:
  application.instanceLabelKey: argocd.argoproj.io/instance
  dex.config: |
    connectors:
      - type: github
        id: github
        name: GitHub
        config:
          clientID: 0000000000478c81c342
          clientSecret: $argocd-github-secret.clientSecret # or $argocd-github-secret:clientSecret

I keep getting this error: Failed to authenticate: github: failed to get token: oauth2: server response missing access_token

[RafPe]

@brandon-piner-aruba I have come across the same problem - however reading the docs does help :) For your reference you can peak on the following doc

and for secret itself just use the following:

apiVersion: v1
kind: Secret
metadata:
  name: sso
  namespace: argocd
  labels:
    app.kubernetes.io/part-of: argocd
data:
  dex.github.clientSecret: Oxxxxx==
type: Opaque

I guess what was missing for this to work was the labels - as the moment I have added those it all worked out of the box! 💪

[joshperry]

We use bank-vaults w/transit so it's easiest for us to use env vars. I found that if you put $ENV_VAR_NAME in a value, you'll see a warning, but the value is passed through to the config file and dex supports env vars in its config.

We set the env: value of the dex pod (helm) to have encrypted values, bankvaults decrypts them, and dex plucks them out of the env.

dex-server time="2023-09-25T20:01:50Z" level=warning msg="config referenced '$GOOGLE_OIDC_CLIENT_SECRET', but key does not exist in secret"

[zebesh]

@joshperry Can you show how you did it?

[saulrobe]

What @RafPe showed worked for me. Here is the docs that should help more: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sensitive-data-and-sso-client-secrets

Basically a couple of things to note:

• If you are making a secret make sure to include a label in the metadata for app.kubernetes.io/part-of: argocd
• If your secret is not named "argocd-secret" then to reference it in the configmap your syntax needs to be $<k8s_secret_name>:<a_key_in_that_k8s_secret>

For example with the secret:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-oidc-client
  namespace: argocd
  labels:
    app.kubernetes.io/part-of: argocd
stringData:
  clientSecret: 'whatevertheactualsecretis'

A helm chart with values similar to the following will use the secret:

# ... other values ...
configs:
  cm:
    dex.config: |
      connectors:
        - type: oidc
          id: oidc
          name: OIDC
          config:
            issuer: https://issuer_address.com/
            clientID: 'whatever_the_client_id_is'
            clientSecret: $argocd-oidc-client:clientSecret
# ... other values ...

Note, in the example the secret is using stringData, but if you use the normal data field remember to base64 encode the value.

[joshperry]

@joshperry Can you show how you did it?

Basically we just patched the argocd dex pod (using kustomize) to set our encrypted transit secret values in environment vars, then put the $ENV_VAR_NAME in the argocd dex configmap. The argo code that injects secrets, like @saulrobe posted, will complain that there's no value with that name. It still passes the $ENV_VAR_NAME intact into the dex container's config file which does support env var replacement, so at start dex will replace env var strings in its config from the container env.

If you're unfamiliar with bank-vaults transit interface, it's much easier to encrypt pod environment vars in a gitops repo because of its init-container hijacking method which is not available for resources that don't have an execution component, like k8s Secrets, or ConfigMaps.