Authorization

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:

# As cluster-admin (full privileges)
kubectl get pods
NAME      STATUS   ROLES   AGE     VERSION
worker-1  Ready    <none>  5d21h   v1.13.0
worker-2  Ready    <none>  5d21h   v1.13.0

kubectl get nodes
NAME      STATUS   ROLES   AGE     VERSION
worker-1  Ready    <none>  5d21h   v1.13.0
worker-2  Ready    <none>  5d21h   v1.13.0

kubectl delete node worker-2
Node "worker-2" deleted!

However, when granting access to other users or services, you’ll want to restrict actions they can perform:

# As developer (restricted privileges)
kubectl delete node worker-2
Error from server (Forbidden): nodes "worker-2" is forbidden: User "developer" cannot delete resource "nodes"

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:

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.

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.

{
  "kind": "Policy",
  "spec": {
    "user":      "dev-user",
    "namespace": "*",
    "resource":  "pods",
    "apiGroup":  "*"
  }
}

Multiple entries require manual edits and an API 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.

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.

ExecStart=/usr/local/bin/kube-apiserver \
  --authorization-mode=AlwaysAllow \
  # (other flags omitted)

To combine multiple modes:

ExecStart=/usr/local/bin/kube-apiserver \
  --authorization-mode=Node,RBAC,Webhook \
  # (other flags omitted)

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.

Links and References

• Kubernetes Authorization Concepts
• RBAC in Kubernetes
• Open Policy Agent (OPA)