Every request passes three gates before it is stored

Study notes

• Every request to the API server goes through three distinct stages, always in this order. Authentication establishes identity: a client certificate, a bearer token, an OIDC token from your identity provider, or a ServiceAccount token for in-cluster workloads. If this fails you get a 401.
• Authorization decides whether that identity may perform this verb on this resource in this namespace. RBAC is the standard mechanism: Roles and ClusterRoles list permissions, bindings attach them to users, groups or ServiceAccounts. A failure here is a 403. The Node authorizer additionally limits a kubelet to objects related to its own node, which limits the damage if one node is compromised.
• Admission is different in kind. By now the caller is known and allowed in principle; admission asks content questions about this specific object. Built-in controllers fill defaults (LimitRanger), enforce quotas (ResourceQuota) and apply Pod Security Standards, and webhooks let you add your own rules. Only after all three does the API server persist the object.
• Practical consequence for debugging: a 401 means fix your credentials, a 403 means fix RBAC, and an admission rejection names the policy that refused it. A pod that simply never appears while its quota is exceeded was refused at admission and never created, which looks different from a Pending Pod.

Deck map