What are authentication, authorization, and admission — and where do they sit in that request flow?

Every request to the Kubernetes API server (kube-apiserver) passes through a strict, sequential pipeline of security controls before it can modify the cluster state or retrieve data. This pipeline ensures that the request comes from a legitimate source (Authentication), is permitted to perform the specific action (Authorization), and that the data payload complies with cluster policies (Admission Control).

The flow follows this specific order: Authentication $\rightarrow$ Authorization $\rightarrow$ Admission Control.

1. Authentication (AuthN): "Who are you?"

Authentication is the first step in the pipeline after Transport Layer Security (TLS) is established,. Its sole responsibility is determining the identity of the requester.

• Mechanism: Kubernetes does not have an internal database of "normal" users (like humans). Instead, it relies on external mechanisms or tokens to validate identity. Common strategies include X.509 Client Certificates, Bearer Tokens (ServiceAccounts, OIDC), or Authenticating Proxies.
• The Output: If successful, the authentication layer strips the credentials and passes a context to the next stage containing the Username, UID, and Groups.
• Engineering Nuance: If a request fails authentication, it is rejected immediately with a 401 Unauthorized. However, if the API server is configured with --anonymous-auth=true, failed credentials (or missing credentials) result in the request being assigned the user system:anonymous and the group system:unauthenticated, allowing it to proceed to the Authorization phase.

2. Authorization (AuthZ): "Are you allowed to do this?"

Once the API server knows who you are, it must determine if you have permission to perform the requested action on the requested resource. This happens immediately after authentication,.

• The Check: The API server compares the request attributes against the active authorization policies (usually RBAC). The attributes checked include the User/Group, the Verb (e.g., get, create, delete), the Resource (e.g., pods), the Namespace, and the API Group,.
• Default Behavior: Kubernetes authorization is "deny by default." If no policy explicitly allows the action, the request is forbidden (HTTP 403).
• Short-Circuiting: If multiple authorizers are configured (e.g., Node Authorization + RBAC), they are checked in sequence. If any authorizer approves the request, it proceeds immediately. If all return "no opinion" or "deny," the request fails.

3. Admission Control: "Is the content valid and compliant?"

Admission Controllers act as the final gatekeepers. Unlike Authentication and Authorization, which look primarily at the request headers (User, Verb, Resource), Admission Control inspects the content (the payload) of the object being created or modified.

Crucially, admission controllers only run on modification requests (create, update, delete, connect). They do not run on read operations (get, list, watch),.

This stage is split into two distinct phases:

Phase A: Mutating Admission

• Purpose: Modification and Defaulting.
• Behavior: These controllers can alter the object before it is stored. For example, if a Pod request does not specify a storageClass for its volume, a mutating controller might inject the default StorageClass.
• Ordering: Mutation happens before validation so that any changes (like adding sidecars or defaults) can be validated.

Phase B: Validating Admission

• Purpose: Governance and Safety.
• Behavior: These controllers accept or reject the request based on the final state of the object. They cannot change the object.
• Example: The PodSecurity admission controller checks if a Pod violates security standards (like running as root) and rejects it if it does. Other examples include validating resource quotas (ResourceQuota) or ensuring image signatures,.

Summary of the Request Flow

Stage	Question Asked	Key Concept	Failure Result
1. Authentication	Who is this?	Identity (User/Group/SA)	401 Unauthorized
2. Authorization	Is this action allowed?	Permissions (RBAC/Verbs)	403 Forbidden
3. Mutation	Should we change this?	Defaults & Sidecars	(Proceeds to Validation)
4. Validation	Is this content valid?	Policy & Schema	422 Unprocessable Entity (usually)
5. Persistence	(Write to Etcd)	Storage	(Success)

If a request passes all three stages, it is validated against the API schema and finally written to etcd, the cluster's backing store.