The Problem with Direct Integration
Connecting Kubernetes directly to Google works fine if all your users have Google accounts. But most enterprises have users spread across multiple systems: Active Directory for employees, GitHub for contractors, SAML for partners. The Kubernetes API server can only be configured with one OIDC issuer. This is where identity brokers solve a real problem.
An identity broker sits between Kubernetes and your various user directories. It speaks OIDC to Kubernetes and speaks whatever protocol each backend requires (LDAP, SAML, GitHub OAuth, etc.).
Dex: The Lightweight Federated OIDC Provider
Dex (developed by the Dex project, now a CNCF project) is purpose-built for this use case. It is minimal, stateless (when using external storage), and designed specifically to act as an OIDC front-end for Kubernetes.
Key characteristics:
- Supports connectors for LDAP, GitHub, GitLab, Google, SAML 2.0, and more.
- Runs as a pod inside the cluster or externally.
- Stores minimal state (just refresh tokens and keys) — can use etcd, SQLite, or PostgreSQL as a backend.
- Commonly used with kubelogin (a kubectl plugin) to handle the browser-based OIDC flow automatically.
A minimal Dex configuration connecting to GitHub declares a connector of type github with the OAuth app's client ID and secret, a callback redirect URI, and the list of GitHub organizations whose members should be allowed to authenticate.
Keycloak: The Full-Featured IAM Platform
Keycloak (Red Hat / CNCF ecosystem) is a complete Identity and Access Management (IAM) solution. It does everything Dex does, plus:
- A full web UI for user management, group management, and role assignment.
- Built-in support for 2FA (TOTP, WebAuthn).
- User self-registration and password reset flows.
- Fine-grained authorization policies beyond simple group membership.
- Session management and token revocation.
When to choose which:
| Concern | Dex | Keycloak |
|---|---|---|
| Complexity | Low — single binary | High — requires a database, more ops overhead |
| Use case | Pure K8s OIDC bridge | Full enterprise IAM |
| User management UI | None | Full-featured |
| 2FA support | Delegated to upstream IdP | Built-in |
| Typical deployment | Small/medium clusters | Enterprise environments |
By using either broker, you decouple your cluster configuration from your corporate user directory. Rotating your LDAP server or migrating from Active Directory to Okta becomes a broker configuration change — not a cluster reconfiguration.