Kubernetes User Identity Management

Kubernetes User Identity Management is the practice of provisioning, authenticating, and governing human user access to a Kubernetes cluster, given that Kubernetes itself stores no user accounts and delegates identity entirely to external systems. Managing user identity well means choosing an authentication mechanism appropriate to the organization's existing infrastructure, mapping that mechanism's output cleanly onto RBAC subjects, and maintaining lifecycle processes — onboarding, credential rotation, and offboarding — that keep cluster access aligned with who should actually have it at any given time.

Authentication Mechanisms for Users

X.509 Client Certificates

The simplest mechanism issues each user a client certificate signed by a certificate authority the API server trusts. The certificate's Common Name becomes the username and its Organization fields become group memberships. Certificates work without any external service but are operationally heavy at scale: Kubernetes has no native revocation list, so revoking a compromised certificate generally requires re-issuing the CA or waiting for expiry, which pushes most organizations toward short-lived certificates issued by an internal PKI.

OpenID Connect (OIDC)

OIDC lets the cluster authenticate users against an existing identity provider — an enterprise SSO system, a cloud directory service, or a self-hosted provider. The user authenticates once with the provider, receives an ID token, and presents it to kubectl (typically through a credential plugin) on every request. The API server validates the token's signature against the provider's public keys and extracts the username and groups from configured claims. OIDC is the recommended approach for organizations that already centralize identity, since it inherits that provider's existing multi-factor authentication, conditional access, and deprovisioning workflows.

Webhook Token Authentication

A webhook authenticator forwards the bearer token from an incoming request to an external service, which returns a TokenReview response confirming or denying the identity. This pattern suits organizations with custom or legacy identity systems that do not speak OIDC natively.

Static Token and Basic Auth Files

Static token files and HTTP basic authentication map credentials from a file loaded at API server startup. Both require a server restart to add or remove a user and store credentials in plaintext on disk, so they are considered legacy options unsuitable for production clusters.

Mapping Identity to Authorization

Username and Group Conventions

Because RBAC bindings reference usernames and group names as plain strings, the identity provider's claim mapping should be designed deliberately — using a stable, non-reassignable identifier (such as an email address or subject ID) as the username, and organizational group names that mirror existing team structures, so that RoleBinding and ClusterRoleBinding objects remain meaningful over time.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-team-admin
subjects:
- kind: Group
  name: oidc:platform-team
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

kubeconfig Distribution

Each user's access is packaged as a kubeconfig file referencing the cluster's API endpoint, CA certificate, and the user's credential (certificate, token, or OIDC plugin configuration). Distributing kubeconfigs securely, and avoiding kubeconfigs that embed long-lived static credentials, is a core part of user identity management in practice.

Lifecycle Governance

Onboarding

New users should be granted access through group membership in the identity provider rather than individual bindings, so that a single group addition in the external system automatically produces the correct RBAC scope inside the cluster.

Credential Rotation and Expiry

OIDC tokens are short-lived by design and refresh automatically through the identity provider; certificate-based access should mirror this by using short validity windows and automated reissuance rather than long-lived certificates that are difficult to revoke.

Offboarding

Removing a user from the identity provider's group immediately removes their effective cluster permissions the next time they authenticate, since Kubernetes re-evaluates group membership on every token presentation. Certificate-based access requires an explicit compensating control, such as CA rotation or an external revocation check, because Kubernetes does not consult a certificate revocation list by default.

Auditing User Access

Access Reviews

Administrators should periodically enumerate RoleBinding and ClusterRoleBinding objects and cross-reference the users and groups listed against the current organizational roster, since a group name persisting in a binding after the corresponding team is dissolved silently retains its original permissions.

Audit Logs

API server audit logs record the authenticated username on every request, giving a durable trail of exactly which human identity performed which action, which is essential both for incident investigation and for periodic compliance review of standing access.