Dex: 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