Kubectl Role-Based Access Control (RBAC) is the line between order and chaos in Kubernetes. It decides who can do what, and where they can do it. Without it, you risk privilege escalation, accidental deletions, or malicious access. With it, you have precision control over every resource.
RBAC in Kubernetes works by defining roles and bindings. A Role sets the rules—what verbs apply to which resources in a namespace. A ClusterRole does the same across all namespaces. A RoleBinding connects a Role to a user, group, or service account inside one namespace. A ClusterRoleBinding links at the cluster level. This structure allows you to define least privilege exactly, without guesswork.
Before applying RBAC, audit your access patterns. Map out every command your teams and services need. Avoid blanket permissions like * or cluster-admin unless absolutely necessary. Test Role and RoleBinding YAML definitions in a staging cluster. Common verbs include get, list, watch, create, update, patch, and delete. Combine only what is required.
A simple Role example:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
To bind it: