K8s Authentication: Proving Who You Are to the API Server

WHY IT EXISTS The Kubernetes API server is the brain of the cluster. Every action—creating a pod, checking logs, scaling a deployment—goes through it. Authentication is the gatekeeper that prevents unauthorized actors from taking over your cluster. Without it, anyone could create, delete, or view anything.

THE MENTAL MODEL Think of the API server as a bank with multiple entrances, each with a different type of guard. One guard checks photo IDs (like OIDC for humans), another checks employee badges (client certs for nodes), and a third checks special access keys (ServiceAccount tokens for pods). Your API request tries each entrance in order until one lets you in. If none do, you're either rejected or treated as an anonymous visitor.

HOW IT WORKS When a request hits the API server, it passes through a chain of configured authenticator modules. Common modules include Client Certificates, Bearer Tokens (from ServiceAccounts or OIDC providers), and Webhooks that call external services. The first module to successfully validate the request's credentials stops the chain. The user's identity (username, UID, and groups) is then attached to the request for the next stage, authorization. If no module can authenticate the request, it's either rejected with a 401 error or treated as an anonymous request from the system:anonymous user.

WHEN TO USE IT Authentication is not optional for any production cluster. The standard practice is to configure a combination of methods: OIDC for human users to integrate with your company's identity provider, ServiceAccounts for in-cluster applications, and client certificates for node-to-control-plane communication.

WHEN NOT TO USE IT The main footgun is misconfiguration. Never grant broad permissions to the system:anonymous user or the system:unauthenticated group, as this can open your cluster to anyone on the network. Also, avoid using static token files in production; they are difficult to rotate and manage securely. A common point of confusion is that Kubernetes itself does not have user objects; a "user" is just a string identity provided by an authenticator.

ONE CANONICAL EXAMPLE A developer runs kubectl get pods. Their kubeconfig file directs kubectl to use an OIDC provider. kubectl obtains a bearer token and includes it in the API request's Authorization header. The API server's OIDC authenticator validates this token, identifies the user as jane.doe@example.com, and passes the now-authenticated request to the authorization layer to check if Jane is allowed to list pods.