The 3 Gates of the API Server

The Path of a Request

Every request to the API Server — whether it comes from a human operator, an automated controller, or a worker node — must pass through three sequential security gates before it is accepted and persisted. If a request fails at any gate, it is rejected immediately and the subsequent gates are never reached.

Gate 1: Authentication (AuthN) — "Who are you?"

The API Server first establishes the identity of the caller. Kubernetes supports several authentication mechanisms simultaneously:

• Client certificates (x.509): The caller presents a TLS certificate signed by the cluster's Certificate Authority. This is how kubectl typically authenticates using the credentials in your ~/.kube/config file.
• Bearer tokens: A token (often a JWT) is passed in the HTTP Authorization header. Service accounts use this mechanism — every Pod gets a service account token automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.
• External identity providers (OIDC): Kubernetes can delegate authentication to an external system like Google, Okta, or Dex, enabling single sign-on for cluster access.

If no authentication method succeeds, the request is treated as coming from the anonymous user (which is typically denied by authorization).

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

Once identity is established, the API Server checks whether that identity has permission to perform the requested action on the target resource. The dominant authorization mode is Role-Based Access Control (RBAC).

RBAC works by binding a Role (a set of allowed verbs on resources — for example, get/watch/list on Pods within a namespace) to a Subject (a user, group, or service account). If the request is "user bob wants to DELETE a Pod in production" and bob only has that read-only pod-reader role, authorization fails and the request is rejected with a 403 Forbidden.

Gate 3: Admission Control — "Is this a good idea right now?"

Admission controllers are plugins that run after authentication and authorization but before the object is written to etcd. They are the most powerful and flexible gate because they can both mutate (modify) and validate (accept or reject) requests.

Examples of built-in admission controllers:

• LimitRanger: Automatically injects default CPU and memory limits into Pods that don't specify them, preventing runaway resource consumption.
• ResourceQuota: Rejects requests that would cause a namespace to exceed its allocated resource budget.
• PodSecurity: Enforces security policies (e.g., "no Pods in this namespace may run as root").

Modern Kubernetes also supports Webhook Admission Controllers — external HTTP servers that the API Server calls out to for custom admission logic. This is how tools like OPA/Gatekeeper and Kyverno enforce organizational policies.