3.11 Kubernetes Control Plane Authorization Path

Kubernetes Control Plane Authorization Path is the specific sequence an already-authenticated request travels through to determine whether it is permitted, describing how the API server evaluates a chain of configured authorizer modules, most commonly RBAC, and how the outcome differs fundamentally from authentication's chain in that any single explicit allow is sufficient regardless of what other authorizers conclude.

A Chain Evaluated for Any Allow

Multiple Authorizers, Any One Sufficient

Like authentication, the API server supports a chain of authorizer modules, but the authorization path differs in its resolution rule: if any authorizer in the chain explicitly allows the request, it is permitted, regardless of whether earlier or later authorizers would have denied it.

Explicit Deny as an Immediate Stop

Some authorizer modules can issue an explicit deny that short-circuits the chain immediately, distinct from simply not expressing an opinion; the authorization path is architected so that most modules effectively abstain unless they find a matching rule, letting the chain continue to the next authorizer.

The RBAC Path Specifically

Matching Identity Against Bound Roles

Within the RBAC authorizer specifically, the path involves gathering every RoleBinding and ClusterRoleBinding applicable to the request's identity and namespace, resolving each to its underlying Role or ClusterRole, and checking whether any of the resulting rules match the request's verb, resource, and API group.

Additive Accumulation Across Multiple Bindings

Because an identity may be granted permissions through several different bindings simultaneously, such as through direct user bindings and through group membership, the RBAC path is architected to accumulate all matching rules from every applicable binding rather than stopping at the first one found.

Falling Through to a Final Denial

Absence of a Match Means Deny

If the request's identity travels through every authorizer in the chain, including every applicable RBAC binding, without any of them producing an explicit allow, the authorization path concludes in denial by default, since Kubernetes's authorization model treats the absence of a granted permission as equivalent to an explicit prohibition.

Where This Path Sits Relative to Admission

Authorization Precedes, Never Follows, Admission

The authorization path is architected to complete entirely before a request reaches admission control; a request that fails authorization never reaches any admission plugin, meaning admission logic can always assume the request it receives was already permitted at the identity-and-verb level.

Authorization Path Diagram