Kubernetes RBAC controls who can perform what actions on which cluster resources — essential for any cluster with multiple users or automated systems needing scoped access. This guide covers configuring RBAC properly.
The Core RBAC Concepts
| Resource | Purpose |
|---|---|
| Role | Defines permissions within a specific namespace |
| ClusterRole | Defines permissions cluster-wide (or reusable across namespaces) |
| RoleBinding | Grants a Role to a specific user/group/service account within a namespace |
| ClusterRoleBinding | Grants a ClusterRole cluster-wide |
Creating a Basic Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]Defines read-only access to pods within the production namespace specifically — no ability to create, modify, or delete, and no access to other resource types.
Binding the Role to a User
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: production
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioCreating a Role for a Service Account (Common for Automated Systems)
apiVersion: v1
kind: ServiceAccount
metadata:
name: ci-deployer
namespace: productionsubjects:
- kind: ServiceAccount
name: ci-deployer
namespace: productionAutomated systems (CI/CD pipelines, for example, see How to Manage Secrets in a CI/CD Pipeline for the credential-handling side) should use scoped service accounts with specific, minimal permissions rather than broad cluster-admin access.
Applying Least Privilege Principles
See How to Implement the Principle of Least Privilege on a Linux VPS for the underlying principle — grant only the specific verbs (get, list, create, delete) and resources genuinely needed for each role's purpose, avoiding blanket wildcard permissions.
Common Predefined ClusterRoles
kubectl get clusterrolesKubernetes ships with several predefined ClusterRoles (view, edit, admin, cluster-admin) representing common permission levels — often a reasonable starting point rather than defining every role from scratch.
Testing What a Specific User/Service Account Can Do
kubectl auth can-i create pods --as=jane --namespace=productionVerify your RBAC configuration produces the actual intended access level, rather than assuming correctness from the YAML definitions alone.
Auditing Existing RBAC Configuration
kubectl get rolebindings,clusterrolebindings -APeriodically review existing bindings for overly broad or no-longer-needed access — RBAC configuration, like any access control system, benefits from regular audit rather than only being reviewed at initial setup.
Avoiding Overuse of cluster-admin
The predefined cluster-admin role grants essentially unrestricted access — reserve this for genuinely necessary cases (initial cluster setup, break-glass emergency access); most users and service accounts should have much more narrowly scoped permissions.
Common Errors
User reports permission denied despite an apparently correct RoleBinding — verify the RoleBinding is in the same namespace as the Role it references (for namespaced Roles), and double-check the exact resource/verb combination matches what the user is actually attempting.
Continue Reading
- How to Set Up Network Policies in Kubernetes for Pod-to-Pod Security
- Kubernetes Namespaces and Resource Quotas Explained
- How to Manage Secrets in a CI/CD Pipeline
Browse more articles in Kubernetes & Container Orchestration.
