Configure Dex with CRDs

[logicfox]

I haven't found any examples of configuring Connectors and OAuth2Clients via CRDs. It would be useful to know how to do this, or add missing support, as this would enable users of an RBAC enabled cluster to configure Dex simply with CRDs.

For instance, I tried creating an OIDC connector based on this struct

apiVersion: dex.coreos.com/v1
kind: Connector
metadata:
  namespace: dex
  name: testconnector
id: atest
type: oidc
name: atest
config:
  issuer: "https://issuer.url"
  clientID: "the-client-id"
  clientSecret: "oh-so-secret"
  redirectURI: "https://dex.application.net/callback/"

but Dex fails while starting up with the error message from this line

failed to initialize server: server: failed to list connector objects from storage: failed to list connectors: json: cannot unmarshal object into Go struct field Connector.config of type []uint8

[srenatus]

Yup, looks like something where some more docs would be helpful, indeed. There's docs, but they could surely be expanded with some config examples.

Does looking at the helm chart help in any way? I'm sorry I've never messed with CRDs much...

[mrwulf]

@logicfox, I agree that it would be really convenient to be able to define clients with CRDs, but this doesn't currently work -- as the documentation states, "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."

[ericchiang]

@logicfox, I agree that it would be really convenient to be able to define clients with CRDs, but this doesn't currently work -- as the documentation states, "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."

Yes, this is unsupported.

[logicfox]

That's unfortunate. Given that all the required information is already there in those CRDs and that the primary use-case for Dex is Kubernetes, would it be possible to implement reading the configuration from storage.go if a configuration flag is set?

[srenatus]

primary use-case for Dex is Kubernetes

Is it? News to me 😅 Dex really works in many settings 😃

That said, I take your point as this being an enhancement that might make sense. 👍

[MatteoJoliveau]

Hi! Sorry to bump an old issue, I just wanted to add a use-case to this topic: GitOps

When following GitOps practices the state of a system is defined in terms of files in Git instead of being imperatively driven via API requests. Having supported access to Dex's CRDs would allow us to define clients in a way that is decoupled from the Dex deployment files (which may live in a separate repository).

Example:

I have an infrastructure repository which holds manifests for Dex and a bunch of other infra-related services (load balancers, Grafana etc)

One developer wants to deploy an internal custom webapp which should authenticate users with the same user pool as the rest of the infra services. Instead of having to edit Dex's configuration file in the infrastructure repository, they could simply add a manifest for a kind: OAuth2Client alongside the rest of the webapp deployment to have it automatically created by Dex.

One example of Kubernetes-enabled system that works this way is ArgoCD which supports creating apps and projects via either a web UI, a gRPC API or by applying custom resources.

Given that Dex already has its own CRDs, I guess supporting this use-case could simply mean adding a validation schema to the CRDs and documenting how to create them via YAML files.

[stefansedich]

Hi! Sorry to bump an old issue, I just wanted to add a use-case to this topic: GitOps

When following GitOps practices the state of a system is defined in terms of files in Git instead of being imperatively driven via API requests. Having supported access to Dex's CRDs would allow us to define clients in a way that is decoupled from the Dex deployment files (which may live in a separate repository).

Example:

I have an infrastructure repository which holds manifests for Dex and a bunch of other infra-related services (load balancers, Grafana etc)

One developer wants to deploy an internal custom webapp which should authenticate users with the same user pool as the rest of the infra services. Instead of having to edit Dex's configuration file in the infrastructure repository, they could simply add a manifest for a kind: OAuth2Client alongside the rest of the webapp deployment to have it automatically created by Dex.

One example of Kubernetes-enabled system that works this way is ArgoCD which supports creating apps and projects via either a web UI, a gRPC API or by applying custom resources.

Given that Dex already has its own CRDs, I guess supporting this use-case could simply mean adding a validation schema to the CRDs and documenting how to create them via YAML files.

We would love this too, our current story for provisioning new apps onto Dex is a bit painful.

[MatteoJoliveau]

Sorry to nudge this issue again, but declarative management of clients and providers is something really we really need in order to integrate Dex in our environment. I would like to ask the maintainers if they have plans for this, or if they want to delegate this to an third party "Dex Operator" project.

IMHO, since Dex already supports CRDs for configuration it would be only natural to use them and promote them to the status of "public API", compared to the current "internal implementation detail".

[sagikazarmark]

We'll add this to the roadmap at some point, but can't promise anything or give an ETA at this point. We are still figuring things out around the CNCF sandbox status, trying to clean up our processes, etc. But I think this is definitely the way Dex needs to head, or at least we need something similar to Prometheus for configuration.

[bonifaido]

IMHO, since Dex already supports CRDs for configuration it would be only natural to use them and promote them to the status of "public API", compared to the current "internal implementation detail".

Dex CRDs are used for storage and not for configuration that is why they are an internal implementation detail.

[MatteoJoliveau]

@bonifaido I know, that's what I'm saying. The fact that Dex already has CRDs means it should not be too complicated to promote them from internal storage implementation to an officially supported way of configuration, aligning Dex's user experience to other projects in the kube world (namely the Argo projects, the operator pattern, etc) and enabling fully declarative Dex deployments

[sagikazarmark]

The fact that it uses CRDs for something (storage in this case) doesn't mean that configuring Dex via CRDs is two clicks away. 🤣

[MatteoJoliveau]

I didn't mean to trivialize the task. I just meant to point out that it's not like Dex has to be integrated from scratch, so I wanted to encourage maintainers to consider this feature.
I'm really happy it's on the roadmap, we'll implement some temporary wrapper while this is getting built to achieve our goals.

[harmjanblok]

Based on the example of @logicfox and reverse engineering of some code, I was able to define a connector with following CRD:

apiVersion: dex.coreos.com/v1
kind: Connector
metadata:
  namespace: dex
  name: atest # id of your connector
id: atest # should match metadata.name
type: oidc
name: 'A test'
# config, as described on https://dexidp.io/docs/connectors/oidc/, converted to json, base64 encoded
config: eyJpc3N1ZXIiOiJodHRwczovL2lzc3Vlci51cmwiLCJjbGllbnRJRCI6InRoZS1jbGllbnQtaWQiLCJjbGllbnRTZWNyZXQiOiJvaC1zby1zZWNyZXQiLCJyZWRpcmVjdFVSSSI6Imh0dHBzOi8vZGV4LmFwcGxpY2F0aW9uLm5ldC9jYWxsYmFjay8ifQo=

metadata.name needs to be encoded for Passwords and OAuth2Clients, see comment on #1606 (comment).