Kubernetes Authorization Management

Kubernetes Authorization Management is the ongoing practice of deciding, configuring, and reviewing what an already-authenticated identity is permitted to do within a cluster. Where authentication answers "who is this," authorization answers "what can they do," and Kubernetes structures that answer through a pluggable chain of authorization modules evaluated on every API request, most commonly built around Role-Based Access Control, with additional modules available for special cases such as node access and external policy delegation.

The Authorization Chain

Sequential Module Evaluation

The API server evaluates configured authorization modules in order for every request; the first module to return an explicit allow or deny decision determines the outcome, and a module that has no opinion passes the decision to the next module in the chain. If no module explicitly allows the request, it is denied by default.

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

Available Modules

RBAC evaluates Role and ClusterRole bindings; Node grants kubelets access scoped to their own node's resources; ABAC evaluates a static policy file (legacy); Webhook delegates decisions to an external service via SubjectAccessReview; and AlwaysAllow or AlwaysDeny are used only for testing, never in production.

Operating RBAC Day to Day

Defining Roles Around Actual Need

Effective authorization management starts from an inventory of what each team, automation, or workload genuinely needs to do, expressed as narrowly scoped Role or ClusterRole objects, rather than starting from a broad built-in role and hoping it happens to be appropriate.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "update", "patch"]

Binding Governance

Every RoleBinding and ClusterRoleBinding created in the cluster represents a standing grant of access; treating binding creation with the same review rigor as a production code change — pull requests, approvals, and a record of who requested the access and why — keeps the accumulated set of grants aligned with actual organizational need.

Reviewing and Verifying Access

can-i and SubjectAccessReview

kubectl auth can-i lets an operator check, before or after granting access, exactly what a given identity is authorized to do, and the underlying SubjectAccessReview API can be queried programmatically to audit access at scale.

kubectl auth can-i delete pods --namespace payments --as system:serviceaccount:payments:billing-worker

Auditing Existing Bindings

Periodically enumerating every RoleBinding and ClusterRoleBinding in the cluster, and cross-referencing their subjects against active users, groups, and service accounts, surfaces stale grants left behind after a team reorganization or a decommissioned workload.

kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide

Handling Special Cases

Multi-Tenant Isolation

In clusters shared by multiple teams, authorization management includes ensuring that ClusterRole bindings scoped to a single namespace via RoleBinding do not inadvertently grant cross-namespace access, and that no team's service accounts hold cluster-wide permissions unless the platform explicitly requires it.

Delegated and External Authorization

When a webhook authorization module is in use, managing authorization also means operating and monitoring the external policy service itself, since its availability and correctness directly gate every API request the module is asked to evaluate.

Change Management for Authorization Policy

Testing Before Applying

Because a misconfigured ClusterRoleBinding can either lock out legitimate operators or grant unintended broad access, changes to authorization policy benefit from dry-run validation (kubectl apply --dry-run=server) and staged rollout in non-production environments before being applied to a production cluster.

Emergency Access Paths

Authorization management should also account for break-glass scenarios — a documented, tightly controlled path to obtain elevated access during an incident when normal request workflows are too slow, without leaving that elevated access as a permanent standing grant afterward.

Continuous Alignment with Least Privilege

Authorization is not a one-time configuration task; workloads and teams change over time, and periodic review of granted permissions against actual usage (informed by audit logs) is what keeps a cluster's authorization posture from drifting toward accumulated, unused privilege.