Kubernetes RBAC Best Practices
Kubernetes has a rich access control system that most teams use incorrectly. The defaults are permissive by design, getting a cluster running quickly is prioritized over secure-by-default configuration. By the time teams think seriously about RBAC, they've already granted cluster-admin to three service accounts and a deployment pipeline, and untangling it requires breaking changes. The hidden te…
- Default to Role and RoleBinding over ClusterRole and ClusterRoleBinding, namespace scope limits blast radius when a service account is compromised
- Set 'automountServiceAccountToken: false' on pods that don't call the Kubernetes API, and audit every service account that does with 'kubectl auth can-i --list'
- RBAC controls who can call the API; admission controllers (Kyverno, OPA Gatekeeper) control what those calls can create, both layers are necessary
- The kube-system default service account and namespace default service accounts accumulate permissions over time, audit them proactively
- Namespace isolation is meaningful for soft multi-tenancy but insufficient for hard multi-tenancy, separate clusters are the right answer when isolation requirements are strict
ClusterRole Versus Role: Scope Determines Blast Radius
This is where most RBAC configurations go wrong first. ClusterRoles operate across the entire cluster, all namespaces, all resources of that type. Roles are namespace-scoped. If a workload only needs to read ConfigMaps in the 'payments' namespace, it needs a Role in that namespace, not a ClusterRole bound cluster-wide. The difference in blast radius if that service account is compromised is the difference between reading one namespace's config and reading every namespace's secrets. The pattern
Service Account Token Scoping Closes Lateral Movement Paths
Every pod in Kubernetes gets a service account, and by default that service account gets an automounted token. Pre-Kubernetes 1.24, those were long-lived JWTs with no expiry and no audience binding, valid forever, usable from anywhere, for any API server call the service account was authorized to make. An attacker who compromised a pod and found the token at '/var/run/secrets/kubernetes.io/serviceaccount/token' had a persistent credential. Modern Kubernetes (1.21+) with projected service accoun
'kubectl auth can-i' Is Your RBAC Audit Tool
RBAC rules are additive and the effective permissions for an identity are the union of all roles bound to it, directly and through group membership. Reading the raw Role and RoleBinding YAML doesn't give you a clear picture of what an identity can actually do. 'kubectl auth can-i' does. The impersonation flag makes it powerful for auditing: 'kubectl auth can-i list secrets --namespace production --as system:serviceaccount:staging:myapp' tells you exactly whether that service account can list se
Frequently asked questions
- How do you migrate an existing cluster with over-permissive RBAC without breaking everything?
- Audit first with 'kubectl auth can-i --list' across all service accounts and identify what's actually being used versus what's permitted. Enable Kubernetes audit logging if it isn't already, it shows you every API call made by every identity, which tells you the actual permission requirement versus the granted permission. Use that data to draft mi…
- What's the right way to grant developers access to debug production pods?
- Avoid giving developers 'exec' access to production pods as a standing permission, 'pods/exec' is effectively a shell on the container, which is a significant privilege. Instead, consider time-limited, audited access through a platform abstraction: a Slack command that creates a time-bound RoleBinding for a specific developer and specific pod, log…
- How do you handle RBAC for CI/CD pipelines that deploy to Kubernetes?
- Deployment pipelines need enough permission to apply manifests, typically 'create', 'update', 'patch', 'delete' on Deployments, Services, ConfigMaps, and whatever other resources your application uses. Scope this to the specific namespaces the pipeline deploys to, never cluster-wide. Use a dedicated service account per pipeline, not a shared deplo…
- Are there RBAC patterns specific to multi-tenant Kubernetes that differ from single-tenant?
- Yes, significantly. In a multi-tenant environment, namespace-admin-equivalent access for individual tenants is the standard pattern, tenants own their namespace, can create and manage resources within it, but cannot see other namespaces or cluster-level resources. The cluster operator retains ClusterRole access. The enforcement challenge is preven…