Kubernetes API Server Authorization Modules

WHY IT EXISTS: After authenticating a user (proving who they are), Kubernetes needs to decide if that user is allowed to perform the requested action (e.g., create a Pod, delete a Secret). Authorization is the "what you can do" step that follows the "who you are" step, forming the core of cluster security.

THE MENTAL MODEL: Think of authorization modules as a chain of security guards at the door to the Kubernetes API server. When a request arrives, it's shown to the first guard. If that guard says "yes," the request is allowed in immediately. If the guard says "I don't have an opinion," the request is passed to the next guard. Only if all guards have been consulted and none have said "yes" is the request ultimately denied.

HOW IT WORKS: The API server is started with the --authorization-mode flag, which specifies an ordered list of modules, for example, Node,RBAC. For each incoming API request, the server checks the modules in that order. The chain stops and grants access on the first "allow" decision. If a module has no opinion, the check continues to the next module. If all modules in the chain return "no opinion" or an explicit "deny", the request is rejected with a 403 Forbidden error.

WHEN TO USE IT: You always use authorization; it's not optional for a secure cluster. The most common and recommended configuration is Node,RBAC. The Node authorizer is a special-purpose module that lets kubelets only modify objects on their own node. RBAC (Role-Based Access Control) is a general-purpose module that grants permissions to users and services based on roles. Other modules exist, like Webhook (to delegate decisions to an external service) and the legacy ABAC (Attribute-Based Access Control).

WHEN NOT TO USE IT: Avoid the AlwaysAllow module in production, as it bypasses all authorization checks, effectively giving every authenticated entity cluster-admin privileges. Similarly, the legacy ABAC module is generally discouraged in favor of the more manageable and auditable RBAC. The order matters: placing a very permissive module early in the chain can render later, more restrictive modules useless.

ONE CANONICAL EXAMPLE: A kubelet on node-1 tries to read a Secret. The API server, configured with --authorization-mode=Node,RBAC, first checks the Node authorizer. The Node authorizer sees the request is from node-1's kubelet and verifies if the Secret is related to a Pod scheduled on node-1. If it is, the Node authorizer returns "allow," and the request succeeds without ever consulting the RBAC module. If not, it returns "no opinion," and the check proceeds to the RBAC module.