Authentication and authorization
Authentication and authorization
Every request to the API server passes three gates.
graph LR
R[kubectl / Pod / controller] --> A1["1. Authentication<br/>who are you?"]
A1 --> A2["2. Authorization<br/>may you do this?"]
A2 --> A3["3. Admission<br/>is this object acceptable?"]
A3 --> E[(etcd)]
A1 -->|unknown| X1[401]
A2 -->|denied| X2[403]
A3 -->|rejected| X3[denied by policy]
Authentication
Kubernetes has no User objects. A user is whatever an authenticator says: a name and a list of groups.
| Method | Typical use |
|---|---|
| X.509 client certificate | admins, break-glass (CN = user, O = groups) |
| ServiceAccount token | Pods, pipelines |
| OIDC | people via Entra ID, Keycloak, Google - the production answer |
| Webhook / cloud IAM | AKS, EKS, GKE integrations |
kubectl auth whoami
Certificates cannot be revoked - a leaked admin certificate is valid until it expires. That is why people should log in with OIDC and certificates stay for emergencies.
Getting a user certificate
The CertificateSigningRequest API lets the cluster CA sign a user certificate without anyone touching the CA key:
sequenceDiagram
participant U as user
participant A as admin
participant K as API server (CA)
U->>U: openssl: key + CSR (CN=jane, O=dev-team)
U->>K: CertificateSigningRequest
A->>K: kubectl certificate approve
K-->>U: signed certificate
U->>U: kubeconfig: cert + key + cluster CA
Authorization
The API server runs authorizers in order - on kubeadm: Node, then RBAC. The first “allow” wins; if nobody allows, the answer is 403. There is no deny in RBAC - everything not granted is forbidden.
kubectl auth can-i create deployments -n dev --as jane
kubectl auth can-i --list --as jane -n dev
--as (impersonation) lets an admin test permissions without the user’s
credentials.