Skip to main content
Kubernetes authentication verifies who you are, while authorization decides what actions authenticated users or services can perform within a cluster. Fine-grained authorization ensures that each role—developer, tester, CI/CD pipeline, or monitoring agent—only has the permissions necessary for its tasks.

​
Why Authorization Matters

Cluster administrators have full control by default:
However, when granting access to other users or services, you’ll want to restrict actions they can perform:
Authorization is critical in multi-tenant clusters to isolate workloads and protect cluster configuration.

​
Kubernetes Authorization Mechanisms

Kubernetes supports several authorization modes, evaluated in order:
The image lists different authorization mechanisms: Node, ABAC, RBAC, and Webhook.

​
1. Node Authorizer

Kubelets use TLS client certificates (user system:node:<nodeName>, group system:nodes) to communicate with the API server. The Node Authorizer automatically grants permissions to read Pods/Services and report node status—nothing more.
The image illustrates a "Node Authorizer" process involving a user, Kube API, and kubelet, with a certificate for authentication. It shows read and write permissions for services, endpoints, nodes, pods, and status updates.

​
2. Attribute-Based Access Control (ABAC)

ABAC policies are static JSON files supplied at API server startup. Each entry matches user, group, namespace, resource, and apiGroup.
Multiple entries require manual edits and an API server restart.
ABAC can become unwieldy in large environments since every permission change needs a file update and server restart.

​
3. Role-Based Access Control (RBAC)

RBAC organizes permissions into Roles (namespace-scoped) or ClusterRoles (cluster-scoped), then binds them to users, groups, or service accounts. Changes to a Role take effect immediately for all subjects.
The image illustrates a Role-Based Access Control (RBAC) system, showing different users and groups with their assigned roles and permissions, such as "Developer" and "Security," with specific capabilities like viewing and creating PODs or approving CSRs.
RBAC is the recommended authorization mechanism for most production clusters.

​
4. Webhook (External Authorization)

With a webhook authorizer, the API server forwards each request to an external HTTP endpoint (for example, Open Policy Agent). The external service evaluates policies and returns an allow or deny response.

​
Fallback Modes: AlwaysAllow and AlwaysDeny

If no authorization mode is specified, Kubernetes defaults to AlwaysAllow, permitting all requests. You can also use AlwaysDeny to block every request.

​
Configuring Authorization Modes

Set the modes via the --authorization-mode flag on the kube-apiserver. The order matters—the API server stops at the first allow or deny decision.
If --authorization-mode is omitted, Kubernetes uses AlwaysAllow by default.
To combine multiple modes:
  1. Node handles kubelet requests.
  2. RBAC authorizes based on Roles and Bindings.
  3. Webhook consults an external service if previous modules neither allowed nor denied.
As soon as one module makes a decision, the API server stops further checks.
Role-Based Access Control in Kubernetes will be covered in more depth later in this course.

Watch Video