What Is RBAC in Kubernetes?

Detailed Answer

RBAC (Role-Based Access Control) is the authorization mechanism that governs who can do what within a Kubernetes cluster. Every request that hits the API server — whether from kubectl, a CI/CD pipeline, or an in-cluster Pod — goes through RBAC evaluation after authentication.

How RBAC Works

Kubernetes processes every API request through a chain: Authentication (who are you?) then Authorization (are you allowed?) then Admission Control (any extra rules?). RBAC handles the authorization step.

RBAC answers one question: Does this subject have permission to perform this verb on this resource?

Subject  +  Verb  +  Resource  =  Allow / Deny
(user)     (get)    (pods)

The Four RBAC Objects

RBAC is built around four Kubernetes API objects that work in pairs:

| Permission Definition | Permission Assignment | |---|---| | Role (namespaced) | RoleBinding (namespaced) | | ClusterRole (cluster-wide) | ClusterRoleBinding (cluster-wide) |

A Role or ClusterRole defines a set of permissions — which API verbs are allowed on which resources. A RoleBinding or ClusterRoleBinding attaches that role to one or more subjects.

A Minimal RBAC Example

Here is a complete RBAC setup that grants a developer read-only access to Pods in the dev namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods-binding
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Key Concepts to Understand

Additive-only model. RBAC has no deny rules. A subject starts with zero permissions. You grant access by creating Roles and Bindings. If no rule grants a permission, the request is denied.

API verbs. The standard verbs map directly to HTTP methods against the API server:

| Verb | HTTP Method | Description | |---|---|---| | get | GET (single) | Read a specific resource | | list | GET (collection) | List resources | | watch | GET (streaming) | Watch for changes | | create | POST | Create a resource | | update | PUT | Replace a resource | | patch | PATCH | Partially modify a resource | | delete | DELETE | Delete a resource |

Subjects. RBAC bindings can target three types of subjects:

• User — an external identity (certificate CN, OIDC token)
• Group — a set of users (certificate O field, OIDC groups claim)
• ServiceAccount — an in-cluster identity for Pods

Verifying RBAC Is Enabled

On most modern clusters RBAC is enabled by default. You can confirm by checking the API server flags:

# On a kubeadm cluster
kubectl -n kube-system get pod kube-apiserver-* -o yaml \
  | grep authorization-mode
# Expected: --authorization-mode=Node,RBAC

Common Built-in ClusterRoles

Kubernetes ships with several default ClusterRoles:

| ClusterRole | Purpose | |---|---| | cluster-admin | Superuser — full access to everything | | admin | Full access within a namespace (no quota/namespace edits) | | edit | Read/write on most namespace resources | | view | Read-only on most namespace resources |

# List all default ClusterRoles
kubectl get clusterroles | grep -v system:

Why RBAC Matters in Production

Without RBAC, any authenticated user or Pod can perform any action in the cluster. This violates the principle of least privilege and creates significant security risk. A compromised Pod with unrestricted access can read Secrets, delete workloads, or escalate privileges cluster-wide.

RBAC is not optional in production. It is the baseline security layer that every team must configure correctly before deploying workloads.