Kubernetes (K8s) is powerful, but with great power comes the responsibility to control who can do what inside your cluster. That’s where RBAC (Role-Based Access Control) comes in. In this blog, we’ll break down how Roles, RoleBindings, and ServiceAccounts work together to enforce fine-grained access control in your Kubernetes clusters.
What is Kubernetes RBAC?
RBAC is a standard Kubernetes authorization mechanism that lets you define who can perform what actions on which resources.
It uses the following key building blocks:
- Role: Defines a set of permissions (verbs like get, list, create) on specific resources.
- RoleBinding: Connects a Role to a user, group, or ServiceAccount within a namespace.
- ClusterRole / ClusterRoleBinding: Similar to Role/RoleBinding, but cluster-wide.
Why RBAC Matters
- Prevents unauthorized access to critical resources.
- Supports principle of least privilege.
- Helps you audit and troubleshoot access issues.
- Essential for multi-tenant or production clusters.
Core Components with Real Examples
Let’s break each one down using a real-world example.
1. Role
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: user-odoo-role namespace: user rules: - apiGroups: [""] resources: ["pods", "services", "configmaps", "secrets"] verbs: ["get"]
This Role allows reading (get) of basic Kubernetes resources in the user namespace.
2. ServiceAccount
apiVersion: v1 kind: ServiceAccount metadata: name: user-odoo namespace: user
This account is used by a pod or controller to interact with the Kubernetes API.
3. RoleBinding
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: user-odoo-role-binding namespace: user roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: user-odoo-role subjects: - kind: ServiceAccount name: user-odoo
This RoleBinding grants the user-odoo ServiceAccount the permissions defined in user-odoo-role.
Use Case: Grant Read-Only Access to Pods
Say you want a monitoring sidecar or script to only read pod data—not modify or delete anything.
Create a Role:
kubectl create role pod-reader \ --verb=get,list,watch \ --resource=pods \ -n dev
Bind it to a ServiceAccount:
kubectl create rolebinding read-pods-binding \ --role=pod-reader \ --serviceaccount=dev:read-only-bot \ -n dev
Common Mistakes to Avoid
- Mismatch between RoleBinding and Role namespaces – both must be in the same namespace.
- Binding to the wrong kind of subject (e.g., user instead of ServiceAccount).
- Giving too broad access by mistake (e.g., using * in verbs or resources).
Tools to Debug RBAC
- kubectl auth can-i --as system:serviceaccount:user:user-odoo get pods
- kubectl describe rolebinding <name> -n <namespace>
These help ensure your bindings are working as expected. Conclusion
Understanding and properly configuring RBAC is essential for secure Kubernetes operations. By assigning precise Roles and binding them to the right subjects, you can confidently control access without compromising security.
Start small, audit regularly, and follow the principle of least privilege. That’s the path to a more secure, maintainable Kubernetes cluster.