Authentication and Authorization
Every request to the API server passes through three gates in order: authentication (who are you?), authorization (are you allowed?), and admission (should this specific request be accepted?). Security in Kubernetes starts here, at the one door everything goes through.
A surprising fact shapes the whole model: Kubernetes has no user objects. It does not manage human accounts at all. Understanding what it does instead — and where it delegates — is the foundation for RBAC and everything above it.
The Request Pipeline
When a request hits the API server, it is authenticated to establish an identity, then authorized against the cluster's policies, then run through admission controllers that can validate or mutate it. Only then is it persisted. Each stage can reject the request. Most of "securing the API" is configuring these three stages well — and they are independent, so a gap in one is not covered by the others.
Authentication: No User Objects
Kubernetes authenticates but does not store users. It supports several authN methods: client certificates, bearer tokens, and — for humans — OIDC integration with an external identity provider. A request arrives with a credential; an authenticator validates it and extracts a username and groups, which are then just strings used by authorization. There is no User resource to kubectl get; identity lives outside the cluster, which is why human access is almost always federated through OIDC or the cloud provider's IAM.
Authorization Modes
Once authenticated, the request is authorized. Kubernetes runs a chain of authorizers; the dominant one is RBAC (Topic 32), with Node authorization for kubelets and optional Webhook authorization to delegate decisions externally. Authorizers are checked in order and the first to allow wins; if none allow, the request is denied. RBAC is where nearly all of your policy lives.
Workload Identity
Humans authenticate via OIDC; workloads authenticate as ServiceAccounts (Topic 33). A Pod presents a projected, short-lived ServiceAccount token, and through workload-identity federation that identity can also be exchanged for cloud IAM credentials — so a Pod calls cloud APIs without any long-lived secret. The clean separation: OIDC for people, ServiceAccounts for Pods, both feeding the same authorization chain.
Authentication — establishes who the caller is — cert, token, or OIDC. Produces a username and groups.
Authorization — decides if that identity may perform the action — chiefly RBAC.
Admission — inspects the specific object and may mutate or reject it after authorization (Topic 36).
- Expecting Kubernetes to manage human user accounts — it has no user objects; identity is external.
- Relying on authentication for authorization — proving who you are is not being allowed to act.
- Distributing long-lived client certificates or tokens to humans instead of federating via OIDC.
- Forgetting admission is a separate gate; passing authZ does not mean a request can't be rejected at admission.
- Granting access to the wrong group string because group membership comes from the external IdP, not Kubernetes.
- Federate human access through OIDC (or the cloud provider's IAM) rather than minting certificates.
- Use ServiceAccounts for workloads and short-lived projected tokens, never embedded credentials.
- Treat authN, authZ, and admission as three independent controls and configure each.
- Keep RBAC as the single source of authorization truth; avoid scattering policy across webhooks unnecessarily.
- Audit which external groups map to which RBAC grants, since membership is defined outside the cluster.
Knowledge Check
In what order does the API server process a request?
- Authentication, then authorization, then admission
- Authorization, then authentication, then admission
- Admission, then authentication, then authorization
- Authentication and authorization happen simultaneously
How does Kubernetes model human users?
- It doesn't store users — identity is external, often via OIDC; authenticators just yield a username and groups
- As namespaced User objects you create and manage with kubectl create user
- As one ServiceAccount per person, provisioned in the kube-system namespace
- As rows in etcd's built-in user table, keyed by login name and synced automatically from the cluster bootstrap config file
How does a Pod authenticate to call the Kubernetes API or cloud services?
- As a ServiceAccount, via a short-lived projected token (exchangeable for cloud IAM credentials)
- By mounting the cluster admin's client certificate and key into the Pod's filesystem
- With a static username and password supplied through a plain environment variable
- Pods cannot authenticate to the API directly and must proxy every call through the node's kubelet process
You got correct