Kubernetes Has No Built-In Users
This surprises almost everyone the first time they encounter it. If you inspect the Kubernetes API, there is no User resource. You cannot run kubectl create user alice. There is no /etc/passwd equivalent inside the cluster.
Instead, Kubernetes outsources identity entirely. It trusts external systems to verify who you are and simply accepts a signed token as proof. This is a deliberate design choice — Kubernetes is infrastructure, not an identity provider. Your organization already has a user directory (Active Directory, Google Workspace, Okta). Kubernetes plugs into that rather than duplicating it.
OIDC: The Standard for Federated Identity
The modern standard for this delegation is OpenID Connect (OIDC) — the same protocol behind "Log in with Google" or "Sign in with GitHub." OIDC is built on top of OAuth 2.0 and adds a standardized identity layer.
The key artifact is the ID Token, which is a JWT (JSON Web Token). A JWT is a base64-encoded, digitally signed JSON document. It contains claims — assertions about the user, such as:
{
"sub": "[email protected]",
"email": "[email protected]",
"groups": ["devs", "platform-team"],
"iss": "https://accounts.google.com",
"exp": 1700000000
}
The token is signed by the Identity Provider (IdP) using a private key. Anyone with the corresponding public key can verify the signature without contacting the IdP again.
The OIDC Authentication Flow:
- Login: Alice authenticates to an external IdP (Google, Okta, Keycloak) using her username and password (or MFA).
- Token Issued: The IdP verifies her credentials and returns a signed ID Token (JWT).
- kubectl Request: Alice's
kubectlcommand attaches the ID Token in the HTTPAuthorization: Bearer <token>header. - API Server Verification: The API server fetches the IdP's public signing certificate (once, at startup or periodically) and uses it to verify the token's signature cryptographically. No live call to the IdP is needed per request — the math of the signature is sufficient proof.
- Identity Extracted: If valid and not expired, the API server extracts the
sub(subject) as the username and thegroupsclaim as group memberships. These feed directly into RBAC evaluation.
Configuring the API Server for OIDC
To enable OIDC, the API server is started with flags pointing to the IdP: the issuer's base URL (from which the API server fetches the .well-known/openid-configuration discovery document to find the public keys), which JWT claim to treat as the Kubernetes username (commonly email or sub), and which claim to treat as group memberships — critical for group-based RBAC.
Interviewers frequently ask: "How does the Kubernetes API server verify a user's identity without storing passwords?" The answer is: it doesn't store passwords at all. It verifies the cryptographic signature on a JWT issued by a trusted external IdP. The API server only needs the IdP's public key — which it fetches once from the OIDC discovery endpoint — to validate every subsequent token. This is stateless, scalable, and decoupled from any specific user directory.