The Kubernetes API server can run several authorization modules — including RBAC, Node, and Webhook. How do multiple modules combine to reach a decision, and what specific problem does the Node authorizer solve?

## The chain Authorization in Kubernetes is a chain of independent modules, configured in order. Each module receives the same request attributes — user, groups, verb, API group, resource, subresource, namespace, object name, or for non-resource requests just the HTTP path and verb — and returns one of three answers: - **Allow** — decision made, chain stops, request proceeds to admission. - **Deny** — decision made, chain stops, 403. - **No opinion** — pass to the next module. If the chain is exhausted with every module abstaining, the default is deny (403). This structure has two consequences worth stating explicitly. First, **order matters** when a module can deny. Second, since **RBAC never denies** — it either finds a matching grant (allow) or abstains — you cannot write an RBAC rule that revokes a permission granted elsewhere. Restriction in RBAC comes from not granting, and any "deny" semantics must come from a webhook authorizer or from admission control. ## The modules **RBAC** — the main event: Roles and ClusterRoles list rules (apiGroups, resources, verbs, optionally resourceNames), and RoleBindings/ClusterRoleBindings attach them to users, groups, or ServiceAccounts. Purely additive, evaluated in memory from cached objects, and fast. **Node** — a bespoke authorizer for kubelets, covered below. **Webhook** — the API server posts a `SubjectAccessReview` to an external HTTPS service, which answers allow or deny. Managed Kubernetes offerings use this to map cloud IAM identities onto cluster permissions. It adds a network hop to authorization decisions, so results are cached (with separate TTLs for allow and deny) and the failure mode needs thought: an unreachable authorization webhook typically means denials, i.e. an unusable cluster. **ABAC** — a legacy file of policy lines requiring an API-server restart to change. Effectively obsolete; proposing it is a red flag. **AlwaysAllow / AlwaysDeny** — test-only. Newer clusters replace the flat `--authorization-mode` list with an **AuthorizationConfiguration** file, which allows multiple webhooks, per-webhook match conditions written in CEL, explicit failure policies, and reordering without the old flag's limitations. ## What the Node authorizer is for Every kubelet must read from the API server: the pods bound to its node, and the Secrets, ConfigMaps, PVCs, and PVs those pods reference. It must also write: its own Node status, its pods' statuses, and events. Expressing that with RBAC alone is impossible in any safe way, because RBAC's granularity is "resource kind, optionally specific names" — it cannot say "the Secrets referenced by pods scheduled here". The only RBAC formulation is a ClusterRole granting `get` on all Secrets to the group `system:nodes`. That means **every node can read every Secret in the cluster**, so compromising one worker — a container escape, a stolen kubelet credential — yields cluster-wide credential theft. The Node authorizer solves this by being graph-aware. It maintains a graph of node → pod → referenced objects, built from the pods actually bound to each node, and authorizes a request from `system:node:<nodename>` only if the target object is reachable in that node's subgraph. Node A cannot read a Secret used only by pods on node B. Two prerequisites: the kubelet must authenticate with a username of the form `system:node:<nodename>` and be in group `system:nodes` (which is what the standard kubelet client certificate provides), and the Node authorizer must actually be first in the chain. ## Why NodeRestriction is its partner Authorization answers "may you touch this object", not "may you set this field". A kubelet legitimately writes its own Node object — but nothing in authorization stops it from writing a *label* claiming its node sits in a special pool, or from editing another node's object. The **NodeRestriction** admission plugin closes that: a kubelet may modify only its own Node and Pod objects, may not set restricted labels (such as node-role or topology labels used for scheduling decisions), and — with the related ServiceAccount token restriction — cannot create tokens for arbitrary ServiceAccounts. This is a compact illustration of the whole pipeline's division of labour: the Node authorizer decides *which objects*, NodeRestriction admission decides *which fields*, and neither could do the other's job. ## Debugging `kubectl auth can-i <verb> <resource> --as <user> --as-group <group>` replays a decision through the whole chain, so it reflects the real answer rather than just RBAC's view. For "why was this allowed?", the audit log records the authorizing decision and, for RBAC, the API server can log the rule that matched. If a webhook authorizer is present, remember that a permission may be granted or refused entirely outside your cluster objects — a common source of confusion on managed platforms.