Skip to main content
This lesson gives a concise overview of how authentication and user management work in Kubernetes — essential background before you work with demos and configuration patterns (profiles, RBAC, multi-tenancy) used later. If you’re unfamiliar with Kubernetes authentication, the examples that follow will be easier to follow after reading this. At a high level, Kubernetes does not manage user accounts inside the cluster. Instead, authentication is delegated to an external identity provider (IdP). Typical IdP choices are LDAP, SSO providers, or OpenID Connect (OIDC) providers such as Google or GitHub. The usual request flow is:
  • A user authenticates with an external IdP (for example, Google, GitHub, or LDAP).
  • The IdP issues a token (ID token or access token).
  • The user presents that token to the Kubernetes API server when making requests.
  • The API server validates the token (using OIDC configuration, a token webhook, or another authentication plugin). If valid, the API server advances the request to authorization (for example, RBAC).
A slide titled "User Management in Kubernetes/Kubeflow" showing a laptop screen with authentication options: LDAP/SSO/OpenID Connect, or sign-in via Google or GitHub.
Why this matters
  • Kubernetes itself has no built-in user store. You cannot create “user” objects inside the cluster the same way you create pods or services.
  • The API server is responsible for verifying presented credentials (tokens, certificates) and producing an authenticated user identity that authorization systems (RBAC, ABAC, etc.) can use.
Common authentication methods Typical authentication flow (short)
  1. User signs in to IdP and receives a token.
  2. User sends token with API request (usually in Authorization: Bearer <token>).
  3. API server validates token and establishes an authenticated user identity.
  4. Authorization (RBAC) uses that identity to allow or deny actions.
A diagram titled "User Management in Kubernetes/Kubeflow" showing a user on a laptop sending a request to a server cluster. The servers display a Kubernetes icon verifying a token and confirming the user (e.g., "User is John").
Kubernetes itself has no notion of a “user” resource. Authentication is handled by external providers (OIDC, LDAP, SSO, client certs, etc.), and Kubernetes verifies tokens or certificates presented by clients.
Dex for local demos and Kubeflow
  • For demos and testing without wiring a production IdP, Kubeflow bundles Dex: a lightweight identity provider and OIDC connector.
  • Dex can manage local users or proxy to other backends (LDAP, GitHub, etc.), so you can sign in and exercise Profiles, RBAC, and multi-tenancy features inside a demo cluster.
Dex is not part of Kubernetes itself — it’s included in Kubeflow deployments to simplify authentication in demo/test environments. Inspecting Dex in a Kubeflow deployment When Kubeflow is deployed, you typically find an auth namespace containing Dex and related resources. For example, to check Dex resources:
Example output:
This output confirms a Dex deployment, a running pod, and a ClusterIP service that exposes Dex inside the cluster. In demo scenarios, signing into Kubeflow typically authenticates you against this Dex server. Practical tips
  • For production, prefer integrating Kubernetes with a managed OIDC provider or corporate SSO rather than using static tokens or local solutions.
  • Use Dex for development and demonstrative purposes, not as a long-term production IdP unless it’s configured to proxy to your corporate identity store.
  • Ensure the API server’s OIDC / token webhook configuration matches your IdP’s issuer, client ID, and public keys for token validation.
References For the remainder of this lesson, we’ll use Dex-managed users so you can follow the Kubeflow profiles, RBAC, and multi-tenancy demos without configuring an external IdP.

Watch Video