← Back to dashboard

Dex

Audience: operator · Profile: both · Read this when: you want one OIDC issuer that both the dashboard and your on-prem clusters trust, so a person and their groups mean the same thing in the dashboard and in kubectl.

Part of OIDC and single sign-on.

Dex can sit between the dashboard and your IdP. It is optional: pointing the dashboard straight at your IdP (OIDC and single sign-on) is the default and stays fully supported. Dex earns its place when you also want clusters to trust the same issuer, so a person and their groups mean the same thing in the dashboard and in kubectl. On-prem (k3s) clusters require it for people. Managed clusters (EKS, GKE, OKE, AKS) stay on their native authentication: Dex for them is paused. To have managed clusters trust Okta, PingOne or another IdP directly, see Kubernetes federation with your IdP.

Dex as the dashboard's SSO issuer

Nothing in the dashboard changes to use it — Dex is just another issuer. On the SSO settings:

Register the dashboard's callback, https://<dashboard>/api/auth/oauth/oidc/callback, as the dashboard client's redirect URI in Dex, and Dex's own callback (https://<dex>/callback) at the upstream IdP. To go back, put the upstream IdP's issuer and client back in these fields.

Dex for on-prem clusters

The dashboard needs Dex's issuer separately from SSO, because the kubeconfig it hands people logs in to Dex with its own public client: Settings → Kubernetes → Dex (dex_issuer_url, dex_k8s_client_id, and dex_ca_pem for a lab Dex with its own CA), then Trusts Dex on the cluster's row. See Kubernetes, where the API-tunnel download for a cloud=local cluster is described.

A lab Dex

A lab Dex on k3s, and the play that makes the k3s API server trust it: examples/playbooks/dex/. Why Dex for people and SPIRE for workloads: design/agent-and-human-identity.md.