A request to the Kubernetes API passes through TLS, then authentication, authorization, admission control, and finally validation and storage. Each stage can reject it, and each returns a different signal. Knowing the order tells you which control to fix when something is blocked or, worse, allowed.
Stage 0: transport
By default the API server listens on port 6443 on the first non-localhost network interface, protected by TLS, according to the docs. In many production clusters it is served on 443. The server presents a certificate, and a client may present a client certificate at this stage.
Stage 1: authentication
Authentication asks who you are. It typically examines headers or the client certificate. Several modules can be configured, and each is tried in sequence until one succeeds. Supported methods include client certificates, passwords, plain tokens, bootstrap tokens and JSON Web Tokens used for service accounts. If the request cannot be authenticated, it is rejected with HTTP 401.
Stage 2: authorization
Authorization asks whether you may do this. The request carries the requester's username, the action and the object affected. If more than one authorization module is configured, each is checked, and if any module authorizes the request, it proceeds. If all deny, the response is HTTP 403.
Note the asymmetry: authorization is a union of grants, so adding a module can only widen access.
Stage 3: admission control
Admission asks whether this particular object is acceptable. Controllers act on requests that create, modify, delete or connect to an object, not on plain reads. They are called in order, and unlike the earlier stages, if any controller rejects, the request is rejected immediately. Admission can also set defaults on fields. Our post on mutating vs validating webhooks covers the order inside this stage.
Stage 4: validation and storage
After admission, the object is validated against its API schema and written to the object store.
Reading the symptom
- 401: authentication failed. Look at certificates, tokens and expiry.
- 403 from RBAC style messages: authorization failed. Look at roles and bindings.
- A denial naming a policy or webhook: admission rejected it.
- A read that works while a write fails: admission does not act on reads, so the cause is likely RBAC or admission on the write.
Why this helps security reviews
When you design a control, pick the stage that fits. Identity questions belong in authentication. Who may act belongs in authorization. What the object looks like belongs in admission. Do not try to enforce object shape through RBAC, which cannot see inside the object.
The docs also point to auditing, which gives a chronological record of actions by users, applications and the control plane itself. That is the evidence trail for all four stages.
Safeguard works before this path starts, on code and manifests, through policies, gates and guardrails. It does not sit in the Kubernetes API path.
Quick check
Which HTTP code means authorization failed?
- Failed authentication returns 401, according to the docs.
Sources
Last reviewed: 19 October 2026.
