Is there a way to create clients without using static clients?

[empath]

the documentation says this:

First, client details should be present in the dex configuration. For example, we could register an app with dex with the following section:

staticClients:
- id: example-app
  secret: example-app-secret
  name: 'Example App'
  # Where the app will be running.
  redirectURIs:
  - 'http://127.0.0.1:5555/callback'

But in the code there's a lot of comments that say something to the effect that this setting overwrites clients saved in the storage back end.

I don't see any way to create clients using the storage back end in the documentation.

Is there a way at all to create those static clients that doesn't involve putting secrets into a k8s config map? I'd like to use a gitops workflow to manage my k8s cluster, but I don't want to commit the configmap with the secret to git.

[mvoelske]

I'm not an expert, but I suppose the gRPC API would be the way to go.

[srenatus]

@empath does that do the trick for you? Can we close this? 😃

[voidengineer]

For a gitops-based workflow in combination with kubernetes it would be great if we only needed to put "OAuth2Client" custom resources into the correct namespace, but the documentation says not to interact with the CRDs directly.

[dungdm93]

Admins should not interact with these resources directly, except while debugging. These resources are only designed to store state and aren't meant to be consumed by end users. For modifying dex's state dynamically see the API documentation.

It make me so confusing...

[jangrewe]

But that API doc says:

The API is [..] not expected to be used by most installations.

So what is actually the "best practice" to create clients, the YAML or the API?

[srenatus]

I suppose the answer depends on your use case. Do you need dynamically created/updated/deleted clients, or is it good enough if the service config drives that? It's all about trade-offs, I'm sorry our docs aren't good guidance for this 😅

[jangrewe]

Okay, so that sounds like it doesn't really matter, both methods are stable and don't have any major drawbacks (only their specific inherent advantages)? Then i'll stick to the YAML, for now. Thanks! 🙂

[srenatus]

@jangrewe I'd say that's accurate. There's some work in progress/planned about changing the gRPC API a bit, but that is likely to become a new API version. Nothing's about to change wrt the config format, I suppose.

[jizusun]

For a gitops-based workflow in combination with kubernetes it would be great if we only needed to put "OAuth2Client" custom resources into the correct namespace, but the documentation says not to interact with the CRDs directly.

New URL for the documentation mentioned above

• https://github.com/dexidp/website/blob/main/content/docs/storage.md#kubernetes-custom-resource-definitions-crds
• https://dexidp.io/docs/storage/#kubernetes-custom-resource-definitions-crds

[jackivanov]

So after 4 years do we have any conclusion?

[jangrewe]

Yes, and it is: yes.

(you may want to read the above comments ;-) )

[DreamingRaven]

Ok so from the original question the issue is they did not want to have their secrets in the values of configmap of dex, not necessarily that they didnt want to use a static client. I got here because I also use GitOps and I wanted to configure my static client with my bitnami-sealed secrets.

So for anyone else who gets here looking for the same, you can use the dex helm chart to use the secret as env vars (https://github.com/dexidp/helm-charts/tree/master/charts/dex#values) using envFrom, or envVars. Once the secret is an environment variable your dex.config in your values can reference the environment variables which will be substituted for you.

So it can look something like this in your helm values (this is only an example to show env vars in use please change this for production use):

dex:
  enabled: true
  fullnameOverride: dex
  envFrom:
  - secretRef:
      name: api-sec
      optional: false
  config:
    # Set it to a valid URL
    issuer: http://dex.example.com
    # See https://dexidp.io/docs/storage/ for more options
    storage:
      type: memory
    # Enable at least one connector
    # See https://dexidp.io/docs/connectors/ for more options
    enablePasswordDB: true
    staticClients:
    - id: traefik-fwd-auth
      name: Traefik Forward Auth OIDC Dex App
      redirectURIs:
      - "https://dex.example.com/_oauth"
      secret: $DEX_STATIC_CLIENT_SECRET
    connectors:
    - type: oidc
      id: auth0
      name: auth0
      config:
        # MUST match what is in /.well-known/openid-configuration/
        issuer: "https://example.uk.auth0.com/"
        # connector config values starting with $ will be env substituted
      clientID: $AUTH0_CLIENT_ID
      clientSecret: $AUTH0_CLIENT_SECRET
      # Dex's issuer URL + "/callback"
      redirectURI: "https://dex.example.com/callback"

[ashmantis1]

Just to add onto @DreamingRaven comment, the config.staticClients[0].secret doesn't seem to work. I had to use config.staticClients[0].secretEnv: DEX_STATIC_CLIENT_SECRET instead, noting the lack of a '$' before the variable name. Very strange inconsistency between connectors and staticClients.

[ifurs]

@jackivanov @empath currently I'm working on it, check this repo. I'm not a developer, so my code could confuse someone, but I promise to make it better. The app simply uses Vault secrets as client definitions and send to Dex gRPC requests to create or update secrets. You could add to Dex helm chart additional container with that app, simply install with pip or use docker image I've pushed to DockerHub. Still this is beta version and before using, check it on your test environment, also you can use app as a reference to create your own, maybe on Go:)

Anyway I would appreciate feedback or any contribution