What is Kubernetes RBAC?
Kubernetes role-based access control (RBAC) is a foundational security layer within Kubernetes. It regulates access to the K8s API and its resources, allowing organizations to define user role names with specific permissions to control who can see or interact with cluster resources. This setup also enforces the principle of least privilege (PoLP) so users can access only the resources their specific role requires, which minimizes potential breaches.
RBAC roles facilitate granular governance over Kubernetes resources so organizations can comply with regulatory standards. That way, they can prevent unauthorized access and mitigate risks by managing access rights—a core component of Kubernetes security best practices.
🚨Kubernetes Security Report 2025
New insights from 200,000+ cloud accounts uncovers the latest risks, attack trends, and security gaps in Kubernetes environments.
Download PDF
Why Kubernetes RBAC matters
Businesses often manage multiple Kubernetes clusters across multiple clouds or environments. This widespread adoption emphasizes the need for stringent security measures to manage distributed systems’ inherent complexities and vulnerabilities.
For example, during a Wiz Tech Talk, VP of product, code, and runtime security Amir Lande Blau referenced a moment with “a pretty large enterprise in the food industry [that had a] pretty good security team.”
He explains that “when we discussed container security with them, their immediate reaction was, ‘Container security? We don’t need that. Like nobody runs containers in here,’ with full confidence. [...] We connected with their environment, and what they saw there was no less than 10,000 containers running across 50 clusters. [...] This huge gap between what they anticipated to see and what they actually saw really captured something.”
This situation shows how complex Kubernetes security can become and why understanding who has each level of access to these containers through RBAC makes all the difference for preventing threats.
Now, it’s time to learn how to use RBAC to rein in your entire cloud security for a unified approach.
Setting up basic Kubernetes RBAC
First, let's go through what it would look like to set up RBAC controls on your Kubernetes cluster:
1. Enable RBAC on your Kubernetes cluster
Ensure that your Kubernetes API server starts with the --authorization-mode flag, including role-based access control.
In Kubernetes, the --authorization-mode flag configures the authorization mechanisms that the API server should use. By including RBAC in this flag, you enable it to control authorization decisions within your cluster.
2. Define Roles and ClusterRoles
Assign Roles within a namespace to grant individual users or pods access to the resources they need:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]However, avoid using asterisks in verbs or resource names unless absolutely necessary—they can unintentionally expose too much access.
ClusterRoles are cluster-wide permissions. Use these for resources that need to be accessible across the entire cluster or for namespaces themselves:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: node-reader
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "watch", "list"]3. Create RoleBindings and ClusterRoleBindings
RoleBindings assign specific permissions in a Role to a user or group of users.
Here’s an example that shows binding the pod-reader role to a user named Carl within the default namespace:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: ci-bot
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioClusterRoleBindings grant the defined permissions in a ClusterRole across the entire cluster.
Below is an example that shows binding the node-reader ClusterRole to all users in the group system:masters:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-nodes
subjects:
- kind: Group
name: system:masters
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: node-reader
apiGroup: rbac.authorization.k8s.ioBy following these steps, you can establish a foundational security model within your Kubernetes environment that controls who can do what. This is critical for application security and data integrity within Kubernetes.
Best practices for open source Kubernetes RBAC
When you adopt RBAC best practices in Kubernetes, they not only enhance your security posture but also yield specific operational benefits. Let’s discuss next how implementing these measures can impact your Kubernetes management:
Enforcing PoLP
By granting the minimum necessary permissions, you can avoid permission misuse, either by accident or due to malicious intent. This focused access control helps you prevent data breaches by ensuring that users and apps can only access the resources they need for their roles.
Here’s an example of assigning roles:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]Regularly reviewing and updating permissions
Regularly updating permissions as roles change within your organization helps you prevent the security risks of over-privileged accounts. This proactive approach ensures that access rights always align with current needs to minimize your network’s attack surface.
One way to ensure this consistency is to adopt a solution like Wiz, which can automate audits and reporting so you can review access and roles pertaining to sensitive data.
Using namespaces to limit scope and enhance Kubernetes security
Namespaces are virtual clusters within Kubernetes that contain resources for specific projects or teams. By limiting the scope of roles, namespaces help you contain breaches within a confined environment and prevent them from spreading across your entire cluster. This isolation aids in damage control and simplifies management.
Teams can organize namespaces by function (like dev, prod, or team) so it’s easier to assign the right roles, limit access, and manage permissions without confusion.
Auditing and monitoring RBAC events
Auditing and monitoring give you transparency into any changes in access patterns—and, as a result, possible security incidents. By logging and analyzing RBAC events, you can detect anomalies early and respond swiftly to unauthorized access attempts. This continuous oversight is crucial for adhering to security policies and regulatory demands.
Automating RBAC policies with policy as code
Automating RBAC using policy as code guarantees consistency within a company’s security settings throughout its ecosystem, without the risk of human error. Tools like Open Policy Agent (OPA) help you enforce these policies dynamically, reduce the operational burden, and enhance compliance across your entire infrastructure.
Here’s an example of OPA in action:
package kubernetes.admission
is_rbac {
input.request.kind.kind == "Role" or input.request.kind.kind == "ClusterRole"
}
deny[msg] {
is_rbac
input.request.object.rules[].resources[] == "*"
msg := "Wildcard resource definitions (*) are not allowed. Please specify resources explicitly."
}
deny[msg] {
is_rbac
input.request.object.rules[].verbs[] == "*"
msg := "Wildcard verbs (*) are not allowed. Please define specific actions."
}
deny[msg] {
is_rbac
input.request.object.rules[].verbs[] == "escalate"
msg := "The 'escalate' verb is not allowed to prevent privilege escalation."
}
deny[msg] {
is_rbac
input.request.object.rules[].verbs[] == "impersonate"
msg := "The 'impersonate' verb is not allowed to avoid privilege escalation."
}
deny[msg] {
is_rbac
input.request.object.rules[].verbs[] == "bind"
msg := "The 'bind' verb is not allowed to prevent assigning roles with elevated privileges."
}Securing sensitive operations with additional checks
Implementing additional verification steps for sensitive operations safeguards your network against unauthorized changes that could impact cluster security. This layered security strategy prevents potential attackers from exploiting high-privilege operations and strengthens security defenses.
Integrating with external identity providers
Using external identity providers streamlines user authentication and management. You can start by integrating Kubernetes with authentication protocols like the Lightweight Directory Access Protocol or OpenID Connect. These steps centralize user credential management and boost security by leveraging robust security infrastructures.
Kubernetes Security Best Practices [Cheat Sheet]
Get a rundown on actionable best practices for securing Kubernetes, from components and network security to pods.
Read more
By implementing the above RBAC best practices, you can secure your Kubernetes environment and improve its management and compliance posture. Each step reduces risks and enhances operational efficiencies so your infrastructure is more secure and easier to manage.
Bonus best practices: 4 advanced tips for K8 RBAC
Below are some additional tips to consider for K8:
Bonus 1: Leveraging RBAC logs for threat detection
Use logs to find access patterns, anomalies, and alerts for strange activity. For example, you may find repeated unauthorized attempts or permission shifts you didn’t know or approve of.
By leveraging RBAC logs for threat detection, you can turn passive logging into an active threat detection process for more efficient responses.
Here’s an example for triggering alerts:
- rule: Repeated Unauthorized Access Attempts
desc: Detect multiple failed access attempts from the same user within a short time window
condition: >
kube_audit and
ka.verb in ("create", "update", "patch", "delete") and
ka.responseStatus.code >= 400 and ka.responseStatus.code < 500 and
ka.user.username != "system:serviceaccount:kube-system:default"
groupby: ka.user.username
aggregate: count(ka.user.username) > 5 over 5m
output: >
Possible brute force attempt detected:
user=%ka.user.username,
verb=%ka.verb,
resource=%ka.objectRef.resource,
attempts=%count
priority: WARNING
tags: [k8s, audit, rbac, threat]Bonus 2: Securing RBAC with wildcard restrictions and role escalation prevention
Wildcard permissions can introduce long-term risks. While they might be helpful now, they could later grant access to future resources you never intended.
To combat this risk, you can define permissions and prevent unwanted access with verbs like escalate and bind. This helps you protect roles and eliminate privilege escalation to avoid future threats.
Bonus 3: Enforcing RBAC best practices with GitOps workflows
As technology and threats evolve, so should your workflows. To accommodate this, include RBAC configuration within your GitOps pipelines so your policy changes reflect appropriate versioning, peer reviews, and consistency across your cloud environment. This automation will also help you implement PoLP and audits.
Bonus 4: Implementing ABAC when necessary
While RBAC provides powerful capabilities, having context within your infrastructure is also important. For example, you can use attribute-based access control (ABAC) to execute granularity for user identity, environment, and other conditions for edge cases. This can add precision during cases where RBAC reaches its limits.
But keep in mind that because Kubernetes rarely enables ABAC by default, you’ll need to explicitly configure it.
Common pitfalls in Kubernetes RBAC implementations
An important but silent threat for DevSecOps is over-permissioned roles. These often overlooked instances can cause highly exploitable events. Misconfigurations—like allowing easy role creation or access to protected resources (such as PersisentVolumes or Certificate Signing Requests)—can also increase security risks.
Instead of falling victim to these sneaky threats, implement the following mitigation tips:
Continuously audit your RBAC settings
Always apply PoLP
Consistently monitor for drift and, when appropriate, realign
Split roles and binding to avoid unintended exposure
It’s best to think of secure Kubernetes access as a living entity within your security posture. As such, you need to nurture and continuously care for it.
RBAC’s critical role in your Kubernetes setup
In Kubernetes, a typical application’s environment consists of nodes, pods, and services that manage networking. You’ll need to properly secure each component to prevent vulnerabilities.
Let’s explore how RBAC helps you mitigate different risks in your Kubernetes ecosystem:
Securing API access: Kubernetes operates via an API for all commands. For example, uncontrolled access could allow malicious actors to manipulate operations, leading to data breaches or disruptions. RBAC mitigates risk by ensuring that only authorized users can execute specific API actions based on roles.
Minimizing insider threats: Not all threats come from outside—some result from insider actions. Without RBAC, users or applications could modify configurations, delete resources, or access sensitive information. RBAC enforces PoLP to provide access only to resources that are necessary for specific functions, which reduces insider risks.
Meeting compliance requirements: Many regulatory frameworks require strict access controls and audit capabilities. For example, RBAC helps organizations comply by providing detailed access controls and logging operations to aid audits.
Managing complex configurations: As Kubernetes environments grow, access rights become complex. That’s where RBAC comes in—it provides a clear framework for defining and managing policies, as well as maintaining order and security.
Enhancing your security posture: Restricting permissions protects your cluster and prevents misconfigurations and vulnerabilities. However, unrestricted access can lead to unauthorized deployments or non-compliant configurations, creating ambiguous “grey zones.” To combat this, DevOps teams can mitigate lateral movement using strict RBAC to prevent broader access, contain breaches, and limit damage if they discover a compromised component.
RBAC creates a dynamic, responsive security environment where access continuously evolves based on threats and operational needs. By implementing it, you can protect your resources and structure operations for scalability, compliance, and advanced security management.
Real-world Kubernetes RBAC examples
Below are two real-world examples of K8s RBAC vulnerabilities that led to security breaches. These highlight the significant risks of misconfigured access controls:
RBAC Buster
The “RBAC Buster” attack campaign involved hackers exploiting misconfigured Kubernetes API servers that accepted unauthenticated requests from anonymous users. The attackers then used this access to implement malicious RBAC policies, create backdoors, and deploy cryptocurrency mining operations within the compromised server.
This incident is a stark reminder of the importance of strict RBAC configurations and the need for continuous security audits to promptly identify and rectify potential vulnerabilities.
Argo CD vulnerability
Another major incident involved a critical vulnerability in Argo CD, a popular application deployment tool within Kubernetes. This vulnerability allowed unauthenticated users to bypass normal verification by exploiting flawed JWT handling, which granted them the same access as admin users. With these elevated privileges, attackers could execute arbitrary commands, alter configurations, or extract sensitive data from the Kubernetes cluster.
This breach underscores the criticality of securing service accounts and endpoints and highlights the cascading effects of security lapses in interconnected tools and platforms within K8s ecosystems.
Secure your Kubernetes RBAC with Wiz
RBAC isn’t just an optional feature within K8s. Implementing it correctly helps you minimize breaches, manage complex configurations, and enforce compliance requirements.
Wiz secures Kubernetes RBAC by revealing the cluster’s architecture and setup, including identities like ClusterRoleBindings, ClusterRoles, RoleBindings, and Roles. By analyzing these components, Wiz identifies risks within Kubernetes identities and configurations.
Additionally, the Wiz Admission Controller enforces security policies in your clusters and blocks deployments or modifications that violate configured policies. These include rules for detecting resource misconfigurations and container image integrity verification.
Finally, Wiz’s Security Graph models relationships between resources to reveal how RBAC settings impact security and expose overly permissive roles or bindings. By integrating Wiz into your CI/CD pipeline, you can shift left on policy enforcement and ensure that only secure, compliant configurations reach your clusters.
Ready to explore more detailed strategies and manage your Kubernetes security more effectively? Sign up for a demo of Wiz today.
