Role Based Access Control (RBAC)

[!IMPORTANT] RBAC (Role-Based Access Control) is the standard method for regulating access to computer or network resources based on the roles of individual users within your organization. In Kubernetes, it is the primary way to enforce the Principle of Least Privilege.

Imagine a secure building. Not everyone should have the master key.

  • Receptionist: Access to the lobby (Read-only).
  • Janitor: Access to all rooms for cleaning (Read/Write to specific resource types).
  • CEO: Access to everything (ClusterAdmin).

Kubernetes uses RBAC to define these rules. It answers the question: “Can this Subject (User/ServiceAccount) perform this Verb (get, list, create) on this Object (Pod, Service)?”

1. The 4 Pillars of RBAC

Understanding RBAC requires mastering four key concepts.

1. Role

Defines permissions within a specific Namespace.

  • "Can read Pods in the 'dev' namespace"
  • Cannot see anything in 'prod'.

2. ClusterRole

Defines permissions across the entire Cluster.

  • "Can read Nodes (which are not namespaced)"
  • "Can list all Pods in ALL namespaces"

3. RoleBinding

Connects a Subject to a Role.

  • Grants the permissions defined in the Role to the User.
  • Confined to the Namespace.

4. ClusterRoleBinding

Connects a Subject to a ClusterRole.

  • Grants permissions cluster-wide.
  • Powerful and dangerous if misused.

2. Interactive: The Permission Logic

How does Kubernetes decide if “Alice” is allowed to “Delete” a “Pod”? It checks the bindings.

Subject

👤 User: Alice
+

Binding

No Binding
→

Access Result

DENIED

Available Bindings (Click to Apply)

Trying to execute: kubectl delete pod my-pod

3. Detailed Manifests

RBAC is defined purely through YAML. Let’s look at the two halves of the equation.

1. The Role (The Permissions)

This file defines what can be done. It does not say who can do it.

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group (Pods, Nodes, Services)
  resources: ["pods", "pods/log"] # What resources?
  verbs: ["get", "watch", "list"] # What actions?

[!NOTE] verbs are the actions. Common verbs are get (read one), list (read many), watch (stream changes), create, update, patch, and delete.

2. The RoleBinding (The Connection)

This file connects the “Who” (Subject) to the “What” (Role).

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can bind to a User, Group, or ServiceAccount
- kind: User
  name: alice # "Alice" is just a string from the certificate/OIDC token
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # Must match the Role name
  apiGroup: rbac.authorization.k8s.io

4. Common Pitfalls & Troubleshooting

1. “I bound the ClusterRole but it’s not working!”

Did you use a RoleBinding or a ClusterRoleBinding?

  • RoleBinding + ClusterRole: This is a common pattern! It gives the user the permissions defined in the ClusterRole, but ONLY within that specific namespace.
  • Example: Use the built-in view ClusterRole, but bind it with a RoleBinding to namespace dev. The user can view resources, but only in dev.
  • ClusterRoleBinding + ClusterRole: Gives permissions everywhere.

2. ServiceAccount vs User

  • Users are global. alice is alice everywhere.
  • ServiceAccounts are namespaced. default:my-app is different from prod:my-app.
  • When binding a ServiceAccount, you must specify the namespace in the subject: ```yaml subjects:
  • kind: ServiceAccount name: my-sa namespace: default # CRITICAL! ```

3. Checking Permissions (The can-i command)

Don’t guess. Ask Kubernetes directly.

# Check your own permissions
kubectl auth can-i delete pods

# Check as another user (impersonation)
kubectl auth can-i delete pods --as alice

# Check in a specific namespace
kubectl auth can-i list secrets --namespace prod