Kubectl Role-Based Access Control (RBAC)

Kubectl Role-Based Access Control (RBAC) is how you decide who can see what, and who can change what, in Kubernetes. Without it, every kubectl command is a loaded weapon. With it, you get fine-grained control at scale.

RBAC in Kubernetes works by binding Roles or ClusterRoles to Subjects—users, groups, or service accounts—through RoleBindings or ClusterRoleBindings. Roles define allowed actions on resources. Bindings attach those permissions to specific identities. You enforce this with YAML files or kubectl commands.

Core RBAC Components

• Role: Grants permissions within a single namespace.
• ClusterRole: Grants permissions cluster-wide.
• RoleBinding: Links a Role to a subject in a specific namespace.
• ClusterRoleBinding: Links a ClusterRole to a subject across the whole cluster.

Creating an RBAC Role with kubectl

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: dev
 name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Apply it:

kubectl apply -f role.yaml

Binding the Role

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods-binding
 namespace: dev
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Apply it:

kubectl apply -f rolebinding.yaml

Key Best Practices

• Grant the least privilege necessary for each subject.
• Prefer Roles over ClusterRoles unless global access is required.
• Avoid binding ClusterRoles like cluster-admin to normal users.

Regularly audit bindings with:

kubectl get rolebindings,clusterrolebindings --all-namespaces

RBAC protects your cluster from accidents and from attackers. It also creates a clear map of responsibility. Every kubectl command is checked against rules you set.

Lock down your Kubernetes access now. See how RBAC can be built, tested, and deployed faster with real-time feedback—try it live on hoop.dev in minutes.