6.11 Kubernetes RBAC (Role-Based Access Control)

🎯 What is RBAC?

RBAC (Role-Based Access Control) is the recommended authorization mechanism in Kubernetes.

It controls:

• Who can access resources
• Which resources they can access
• What actions (verbs) they can perform
• In which namespace (or cluster-wide)

---

🧩 RBAC Core Components

Object	Purpose
Role	Defines permissions (namespace-scoped)
ClusterRole	Defines cluster-wide permissions
RoleBinding	Links user/group to Role
ClusterRoleBinding	Links user/group to ClusterRole

---

🏗 Creating a Role

Example: Developer role in default namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]

Apply:

kubectl apply -f developer-role.yaml

Note

Empty apiGroups: [""] represents the core API group.

---

🔗 Creating a RoleBinding

Link dev-user to the developer role:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
  namespace: default
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f devuser-binding.yaml

---

📂 Namespace Scope

Roles and RoleBindings are namespace-scoped.

• Access applies only within that namespace.
• To grant cluster-wide permissions → use ClusterRole.

Warning

Avoid ClusterRole unless absolutely required.

---

🔎 Viewing RBAC Objects

kubectl get roles
kubectl get rolebindings
kubectl describe role developer
kubectl describe rolebinding devuser-developer-binding

---

✅ Checking Access

Check current user access (user: dev-user):

kubectl auth can-i create deployments

Impersonate another user:

kubectl auth can-i create pods --as=dev-user
kubectl auth can-i create pods --as=dev-user --namespace=test

Tip

Use kubectl auth can-i to validate RBAC before giving users access.

---

🎯 Restricting to Specific Resources

You can restrict permissions to specific resource names:

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "create", "delete"]
  resourceNames: ["blue", "orange"]

This allows access only to pods named blue and orange.

---

🛡 Production Best Practices

✅ DO

Success

• Follow principle of least privilege
• Use namespace isolation
• Prefer Roles over ClusterRoles
• Review RoleBindings periodically
• Use groups instead of individual users
• Audit access regularly

---

❌ DON'T

Danger

• Do NOT grant cluster-admin broadly
• Do NOT use wildcard verbs (*)
• Do NOT mix dev and prod access
• Do NOT leave unused RoleBindings
• Do NOT grant write access when read is enough

---

🚨 Production Risks

Risk	Impact
Over-permissive role	Privilege escalation
ClusterRole misuse	Full cluster compromise
No namespace isolation	Cross-team interference
No access review	Security drift

---

🔐 RBAC vs ABAC

RBAC	ABAC
Dynamic	Static policy file
No API restart	Requires restart
Scalable	Hard to maintain
Production ready	Legacy approach

---

🎯 Summary

• RBAC controls permissions via roles
• Roles define rules (apiGroups + resources + verbs)
• RoleBindings assign roles to users/groups
• Namespace scoping is critical for multi-team clusters
• Always follow least privilege

---

Quote

RBAC is not about giving access.
It is about carefully limiting access.