Authentication and Authorization

An API that anyone could call and do anything on would be catastrophic. Every request must prove who it is (authentication) and be checked for what it's allowed to do (authorization) before it takes effect.

Solution: Make every request pass authentication (certs/tokens), then authorization (RBAC), then admission control before it is stored.

At the port gate a guard does two separate jobs in order. First they check your ID to confirm you really are who you claim to be, that step is authentication. Then they check which doors your badge is allowed to open, that step is authorization, and you can clear the first check yet still be turned back at a locked door. Kubernetes runs the same two gates on every request: AuthN establishes your identity from a cert or token, then AuthZ asks RBAC which actions that identity may actually perform.

The same cluster entities appear in every day's notes; the diagram below shows where this day's topic fits.

Every API call runs a fixed gauntlet: it is first authenticated, then authorized, then checked by admission control before being stored.

Graph legend — each node maps to a concrete api-server stage:

AuthN = identity. AuthZ = permission. You can be authenticated and still get a Forbidden because you are not authorized.

The API server has no user database. Identity comes from:

   - client CERTIFICATES (CN = user, O = group)   <- common
   - bearer TOKENS (service accounts, or OIDC via Dex / Keycloak / Okta)
   - static token / basic auth files (rarely, legacy)

Your kubeconfig is basically your keycard: it holds the server address, the CA to trust, and your client cert/key (or token).

kubectl get pods --kubeconfig config   # use a specific kubeconfig
kubectl get pods                       # defaults to ~/.kube/config

Raw API call with explicit creds (what kubeconfig does under the hood):

kubectl get --raw /api/v1/namespaces/default/pods \
  --server https://localhost:64418 \
  --client-key adam.key \
  --client-certificate adam.crt \
  --certificate-authority ca.crt

After identity is known, the API server checks authorization modules in a configured order; the first to decide wins:

   Node     -> authorizes kubelets to access what their node needs
   ABAC     -> attribute-based, file of policies (hard to manage)
   RBAC     -> role-based, the RECOMMENDED approach (Day 23-24)
   Webhook  -> delegate to an external service (e.g. OPA)

AlwaysAllow / AlwaysDeny modes exist but are for testing only.

These commands let you ask the API server who you are and whether a given action is permitted, optionally impersonating another user.

kubectl auth whoami                 # who the API server thinks you are
kubectl auth can-i create pods                  # for yourself
kubectl auth can-i delete nodes --as adam       # impersonate to test
kubectl auth can-i '*' '*'                       # am I admin?

Putting it together, a request flows from your kubeconfig credentials through authentication, authorization, and admission before the action runs.

Follow one kubectl apply through every gate the API server runs.

Graph legend — each step maps to a concrete api-server action:

Every API request runs the same gauntlet of gates before anything is stored.

Graph legend — each node maps to a concrete request stage:

• Every request is authenticated then authorized (then admission).
• API server has no user store — identity comes from certs or tokens.
• kubeconfig carries server + CA + your credentials.
• Authorization order: Node -> RBAC -> Webhook; RBAC is what you'll use.
• Use kubectl auth can-i ... --as <user> to test permissions.

• [ ] Can explain AuthN vs AuthZ in one sentence each
• [ ] Inspected ~/.kube/config and identified server/CA/credentials
• [ ] Made a --raw API call with explicit cert flags
• [ ] Used kubectl auth can-i with --as to test access