Kubernetes-native connector/client config

[ghf20]

We've been running dex on EKS for a while and ended up building an internal controller to handle connector and client
management. I wanted to share what we built and ask whether there's appetite for something like this upstream.

What we built and why

The goal was developer self-service: app teams shouldn't need to file a ticket or touch a central dex config file to
onboard their application to SSO. They should be able to declare what they need as part of their own Helm chart and
have it just work.

Our controller (sso-controller) makes that possible today. When an app team wants SSO, they add a namespaced
DexClient CR and an ExternalSecret to their chart - both live in their own namespace alongside the rest of their app.
On merge, ArgoCD picks it up, the controller reconciles it, and their connector and OAuth2 client are registered with
dex.

The full GitOps loop looks like this:

1. App team adds DexCR + ExternalSecret to their chart (credentials pulled from External Vault via
   External Secrets Operator)
2. PR merged -> ArgoCD syncs the namespace
3. Controller picks up the new CR, copies secrets to the dex namespace, writes connector and client entries into the
   dex ConfigMap
4. Dex pod restarts with the updated config

It works, and it's fully integrated into our platform. But there are a few things that bother us about it:

• Pod restarts on every change. A new app onboarding or a secret rotation causes a rolling restart of dex.
• Secret values land in the ConfigMap. We copy the actual credential values in rather than referencing them, which
  means plaintext secrets in a ConfigMap instead of proper Kubernetes Secret objects.
• Not true GitOps The ExternalSecret and DexCR CR are clean declarativeresources in git. But then the controller has to step outside that model and mutate a central ConfigMap that isn't owned by any single application. When something goes wrong it's hard to debug.
• It only covers our connector type (Azure AD via OIDC). Adding other providers means extending the
  controller ourselves and maintaining that mapping indefinitely.
• It's a separate thing to maintain that stays in sync with dex internals by parsing and rewriting config.yaml.

Why not the gRPC API?

I'm aware of CreateConnector/UpdateConnector behind the api_connectors_crud feature flag. The flag being off by
default and the API being marked experimental made us hesitant, but the bigger gap is that connector config (including
secrets) goes directly in the request payload. There's no way to say "get the clientSecret from this Kubernetes Secret"

• you have to resolve it first and send the value, which puts us back to the same secrets-in-plaintext problem.

What we'd want instead

A built-in reconciler that watches namespaced CRDs and manages connectors and clients without restarts. The
self-service story stays the same - app teams declare what they need in their own namespace and it gets reconciled
automatically - but the implementation is cleaner end-to-end:

• No central ConfigMap that every app's controller is racing to mutate
• No secret copying across namespaces - the connector CR references a Secret in its own namespace and dex reads it at
  reconcile time
• No pod restarts - getConnector already checks ResourceVersion and lazy-reloads from storage on mismatch, so the
  infrastructure for live updates is already there
• The declared state in git actually matches what's running, with CR status conditions surfacing sync errors back to
  app teams via kubectl

Something like:

apiVersion: config.dex.io/v1alpha1
kind: DexConnector
metadata:
  name: azure-ad
  namespace: identity
spec:
  type: oidc
  name: "Azure AD"
  config:
    issuer: "https://login.microsoftonline.com/<tenant>/v2.0"
    redirectURI: "https://dex.example.com/callback"
    getUserInfo: true
  secretRefs:
    - configField: clientSecret
      valueFrom: { name: azure-ad-creds, key: clientSecret }

The important properties we'd want:

• Works with any storage backend (we're not using the Kubernetes storage backend)
• Additive alongside staticConnectors/staticClients - base config untouched
• Secrets referenced from Kubernetes Secrets, not embedded
• No new runtime dependencies

We have a working internal implementation and would be willing to contribute it upstream if there's interest. Happy to
write a full DEP.