Kubernetes Control Plane Authorization Path

Kubernetes Control Plane Authorization Path is the specific sequence of steps a resolved identity's request travels through to determine whether the requested action is permitted, tracing the chain of configured authorization modules, most commonly Node, RBAC, and Webhook, in the exact order they are consulted, and the specific rule-matching logic each module applies to decide allow, deny, or defer.

The Authorizer Chain

Ordered Modules, First Decisive Answer Wins

The API server formally holds a configured, ordered list of authorization modules; each is asked in turn whether the identified request should be allowed, and the chain formally stops at the first module that returns an explicit allow or deny, with modules that abstain (no opinion) simply passing evaluation to the next module in the chain.

kube-apiserver --authorization-mode=Node,RBAC

Default Deny

If every configured module abstains without an explicit decision, the request is formally denied by default; authorization in Kubernetes is deny-by-default, requiring some module to affirmatively grant access rather than requiring an explicit deny rule to block it.

Node Authorization

A Narrow, Purpose-Built Module

The Node authorizer formally grants kubelets access only to the specific subset of API operations they legitimately need for the node they represent, reading Pods, Services, and Secrets bound to their own node, and writing status back for objects they own, denying any attempt by a kubelet's credentials to act on resources outside that narrow, node-scoped set.

kubectl get --raw /api/v1/nodes/worker-node-3/proxy/pods

RBAC Authorization

Rule Evaluation Against Bound Roles

For requests not already resolved by the Node authorizer, the RBAC module formally evaluates every Role and ClusterRole bound to the requesting identity, directly or through group membership, checking whether any bound rule's apiGroups, resources, and verbs match the request; a single matching rule anywhere across every applicable binding is sufficient to grant access.

kubectl auth can-i delete pods --as system:serviceaccount:codartium-team:codartium-controller -n codartium-team

Namespace Scoping Within the Path

A RoleBinding's own namespace formally constrains which requests its referenced Role or ClusterRole applies to; the RBAC module evaluates only bindings whose namespace matches the request's namespace, alongside any ClusterRoleBindings, which apply cluster-wide regardless of the request's namespace.

Webhook Authorization

Delegating the Decision Externally

Where a webhook authorization module is configured, an unresolved request is formally sent to an external HTTPS service as a SubjectAccessReview, which responds with an allow, deny, or no-opinion result, evaluated at this same point in the chain as Node or RBAC, allowing custom authorization logic to participate without modifying the API server itself.

apiVersion: apiserver.k8s.io/v1beta1
kind: WebhookConfiguration
webhook:
  configPath: /etc/kubernetes/webhook-authz-config.yaml

kubectl create -f - <<'EOF'
apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
spec:
  user: system:serviceaccount:codartium-team:codartium-controller
  resourceAttributes:
    namespace: codartium-team
    verb: delete
    resource: pods
EOF

ABAC as a Legacy Path

Attribute-Based Policy File

An older, largely superseded authorization mode, ABAC, formally evaluates requests against a static policy file of attribute-matching rules loaded at API server startup, requiring a full API server restart to apply any policy change, a rigidity that led to RBAC's adoption as the standard mechanism for dynamic, API-managed authorization policy.

Path Termination

Explicit Allow

The authorization path formally terminates the moment any module in the chain returns an explicit allow, immediately handing the request off to admission control without consulting any remaining modules in the chain.

Explicit or Default Deny

The authorization path formally terminates in rejection either when a module explicitly denies the request or when every module abstains and the chain's default-deny behavior applies, returning an HTTP 403 response before admission control is ever reached.

kubectl auth can-i '*' '*' --as system:anonymous

Why the Authorization Path Is Structured as a Chain

Chaining Node, RBAC, and optionally Webhook authorization, evaluated in order with a deny-by-default fallback, is what formally allows a narrow, purpose-built module like Node authorization to handle its specific, well-understood case efficiently and restrictively, while RBAC handles the general case of arbitrary user and ServiceAccount permissions, and Webhook authorization extends the chain to organization-specific logic, all without any one module needing to understand the others' concerns.