Understanding Kubernetes RBAC
Beyond the Basics—Dynamic Policies & Real-World Wins
Kubenatives Newsletter - Edition #11
RBAC (Role-Based Access Control) is one of Kubernetes' most critical security features, yet it’s also one of the most misunderstood. Many teams either over-permission users or struggle with complex RBAC policies.
Today, we’ll go beyond the basics and dive deep into fine-tuning access control, preventing privilege escalation, and implementing advanced RBAC strategies.
RBAC 101: A Quick Refresher
RBAC in Kubernetes governs who can perform what actions on which resources. It consists of four key objects:
Role – Defines permissions within a specific namespace.
ClusterRole – Defines permissions cluster-wide.
RoleBinding – Grants a Role to a user, group, or service account.
ClusterRoleBinding – Grants a ClusterRole cluster-wide.
Now, let’s go beyond the basics and see how you can tighten security and optimize access.
🔹 Common Pitfalls and How to Avoid Them
🚨 1. Overusing Cluster-Wide Privileges
Giving cluster-admin or edit permissions to every developer is a security risk. Instead, use namespace-specific Roles and bind them carefully. Example:
✅ Better Approach: Use RoleBinding to limit access per namespace instead of using ClusterRoleBinding.
🔐 2. Enforcing Least Privilege
You should always follow the Principle of Least Privilege (PoLP). Here’s a bad example:
This gives complete control over all API objects in the dev namespace—a recipe for disaster! Instead, only grant minimal permissions:
🚀 Advanced RBAC Concepts
📌 1. Using Aggregated ClusterRoles
Instead of manually assigning multiple ClusterRoles, Kubernetes lets you aggregate roles dynamically. This is useful for plugins and extensions.
This automatically extends the view ClusterRole to include log reading without modifying existing bindings.
📌 2. Restricting Service Account Impersonation
By default, Kubernetes allows any authenticated user to impersonate a ServiceAccount if not explicitly restricted. This can be abused to escalate privileges.
How to prevent impersonation attacks?
Explicitly deny the impersonate verb:
Then bind it to prevent escalation:
📌 3. Managing RBAC with GitOps (ArgoCD or Flux)
RBAC should be version-controlled like application configurations. Here’s how you can store RBAC policies in Git and apply them via ArgoCD.
Example GitOps RBAC Policy in a Git Repository:
Then deploy it with ArgoCD:
✅ Benefits:
Auditable RBAC changes in Git.
Automated policy enforcement.
Rollback capabilities.
🔍 Troubleshooting RBAC Issues
RBAC misconfigurations can be frustrating. Use these tools:
✅ Check What a User Can Do
✅ Debug Denied Actions
✅ List RoleBindings
Real-World Win: RBAC for Multi-Tenant Clusters
Multi-tenancy is a hot topic, and RBAC is your bouncer at the door. I recently spoke with a Kubenatives subscriber running a shared cluster for 10 teams. Their challenge? Keeping teams in their lanes without drowning in RoleBindings.
Their Solution:
Namespace-per-Team: Each team gets a namespace (e.g., team-a, team-b).
Team Admin Role: A Role with verbs: ["*"] on most resources, but restricted from secrets and networkpolicies for compliance.
Label-Based Automation: A controller watches for new namespaces with tenant: team-x labels, auto-applying the Role and RoleBinding.
Result: Onboarding a new team takes seconds, not hours. Check their open-source script here (link placeholder—swap in your own if you’ve got one!).
Tool Spotlight: rbac-tool
Tired of eyeballing YAML for gaps? Try rbac-tool (github.com/alcideio/rbac-tool). Run rbac-tool viz to generate a visual map of your cluster’s permissions. It’s like X-ray vision for RBAC—spot over-privileged service accounts in seconds.
Reader Challenge
Here’s your mission: Audit one ClusterRole in your cluster this week. Look for:
Unused verbs (e.g., delete when no one deletes).
Wildcards (*) that could be tightened. Share your findings with me on X—I’ll feature the wildest over-permission in Edition #12!