RBAC (Role-Based Access Control) in Kubernetes provides flexible access control but easily turns into a maze of Role, ClusterRole, RoleBinding and ServiceAccount. Here are simple patterns, common mistakes and how to keep permissions transparent.
Basics
Role – permissions within a single namespace. ClusterRole – cluster-wide permissions or a reusable role for multiple namespaces. RoleBinding links a role to a user or ServiceAccount. For in-cluster applications use ServiceAccount – not personal accounts.
Common Mistakes
- Overly broad permissions – cluster-admin "just in case". Better to start with minimal rights and expand as needed.
- Forgotten ServiceAccount – pod runs with default SA which lacks required permissions. Create a dedicated SA and specify it in spec.serviceAccountName.
- RoleBinding in wrong namespace – Role is scoped to namespace A, but Binding was created in B. Check that subject and role match in context.
Practical Patterns
For dev team: Role with get/list/watch on Deployment, Pod, Service in their namespace. For CI/CD: ServiceAccount with create/update rights in target namespaces. For monitoring: ClusterRole with get/list on metrics and events. Platforms like Opsy AI help manage RBAC through a unified interface and suggest minimal permissions.
Summary
RBAC doesn't have to be complex. Start with a clear scheme: who should do what, create roles for those scenarios, bind to ServiceAccount or users. Regularly review permissions – over time excess accumulates. See also: What is GitOps and Kubernetes Without Helm.