Kubernetes RBAC
Role-Based Access Control for K8s — roles, bindings, and service accounts.
ContainersAdvanced
Why
RBAC limits what users and service accounts can do in K8s. Roles define permissions, RoleBindings grant them to subjects.
Default deny — explicit allow.
When
Use RBAC for all production clusters — least privilege for every service account. Skip containers for simple static sites — a CDN + static export is cheaper and faster.
Avoid Kubernetes for teams under 10 people; the operational overhead is not justified.
How
1. ServiceAccount — identity for pod
2. Role — namespaced permissions
3. ClusterRole — cluster-wide permissions
4. RoleBinding — grant Role to subject
5. ClusterRoleBinding — grant ClusterRole
6. verbs — get, list, create, update, delete
7. resources — pods, services, deployments
Example
# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: myapp }
# role.yaml — read-only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: reader }
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]
# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: reader-binding }
subjects:
- kind: ServiceAccount
name: myapp
roleRef: { kind: Role, name: reader, apiGroup: rbac.authorization.k8s.io }
# Use in pod
spec:
serviceAccountName: myapp
Common Problems
- ⚠Forbidden errors — service account lacks permission, check RoleBinding
- ⚠Over-permissive — using cluster-admin, create specific Role with least privilege
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Use least privilege — only grant verbs needed, never cluster-admin for apps
- ✓Use ServiceAccount for pods — not default, assign specific with minimal Role
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit