--- title: "Guide to Kubernetes RBAC" description: "Learn about Kubernetes RBAC, its core objects, and challenges such as scalability, manual management, and auditing. Discover best practices and how Cerbos helps simplify RBAC for Kubernetes, ensuring security and compliance with minimal effort." author: "Tania Duggal" date: "2025-03-17T12:28:54.966Z" canonical: "https://dev.to/cerbos/introduction-to-rbac-in-kubernetes-5hh5" image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Guide_to_Kubernetes_RBAC_1f736c405b.png" tags: ["guide"] source: "https://www.cerbos.dev/blog/guide-to-kubernetes-rbac" --- # Guide to Kubernetes RBAC In this article, you will learn what RBAC is, the key challenges and approaches to managing RBAC in Kubernetes, and how [Cerbos](https://www.cerbos.dev/) can help you in your application security. In Kubernetes, when a request comes to the API Server to create resources, it processes the request in different steps. It first checks from where a request is made and whether a user is valid or not. This process is called authentication. There are two categories of users: normal users and service accounts. Service accounts are managed internally by Kubernetes, and are used by applications that access the cluster, such as the Monitoring Application. Normal users are external entities that may include administrators, developers, and other humans. After authentication, the next process is [authorization](https://www.cerbos.dev/blog/authorization-as-a-service) for the requested action and permissions. While Kubernetes supports multiple authorization methods, the one we’ll concentrate on in this article is called [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac). ![kubernetes rbac.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/kubernetes_rbac_02aff3fd0a.png) ## What is RBAC? RBAC stands for [Role Based Access Control](https://www.cerbos.dev/features-benefits-and-use-cases/rbac). It is a method through which we can control access to resources and actions based on the roles assigned to the users. In Kubernetes, RBAC is how the administrator can control and allow which actions the users can perform on which resources, respectively. RBAC is managed just like everything else in Kubernetes: as objects that can be described via YAML or kubectl. To enable RBAC, the `--authorization-mode` flag must be set to RBAC when starting the API server. ``` kube-apiserver --authorization-mode=RBAC ``` ## Core objects of Kubernetes RBAC The RBAC API declares four core objects. These are: 1. **Role**: It is a way of defining what actions users can perform within a namespace. This defines which actions such as get, list, create, delete, etc., can be performed on specific resources like pods, services, and deployments. 2. **Cluster Role**: This is similar to the role, but it is used for cluster-wide permissions. It means it is not limited to a specific namespace and can be used in all namespaces of the cluster. 3. **RoleBinding**: RoleBinding binds the role with one or more users, groups, and service accounts in a particular namespace. In this way, whatever permissions we have defined in a role get allotted to the users, groups, or service accounts. 4. **ClusterRoleBinding**: ClusterRoleBinding binds the ClusterRole to one or more users, groups, and service accounts throughout the cluster. This allows the permissions defined in ClusterRole to be assigned to users in all namespaces of the cluster. ## How RBAC is implemented in Kubernetes It depends on your requirements and what you want to create for your resources, whether it be a Role or a ClusterRole. ### Create a role and assign it with RoleBinding ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: default rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "list", "update", "delete", "create"] ``` We have permitted pods to get, list, update, delete, and create the resources. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: devuser-developer-binding subjects: - kind: User name: dev-user # "name" is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer apiGroup: rbac.authorization.k8s.io ``` RoleBinding binds the **developer** Role to a user named **dev-user** in the default namespace. ### Create a ClusterRole and assign it with ClusterRoleBinding ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-administrator rules: - apiGroups: [""] # "" indicates the core API group resources: ["nodes"] verbs: ["get", "list", "delete", "create"] ``` We have permitted nodes to get, list, delete, and create the resources. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-admin-role-binding subjects: - kind: User name: cluster-admin apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-administrator apiGroup: rbac.authorization.k8s.io ``` ClusterRoleBinding binds the **cluster-administrator** ClusterRole to a user named **cluster-admin** in all namespaces. ## Challenges in Kubernetes RBAC 1. **Difficulty in management**: It's difficult to manage RBAC in Kubernetes when you have so many roles and permissions. Each user and service requires particular permission, which can be time-consuming and complex. As the number of users, applications, and namespaces grows, it becomes difficult to handle the RBAC configuration. _For example, if you have a team of developers in different namespaces, you must ensure that each developer can only access the resources that they need. Mistakenly, if any developer gets too many permissions, they can unintentionally modify other's resources._ 2. **Scalability issues**: As the organization grows, so does the number of users and roles. This growth is asymmetrical, and the challenge of scaling RBAC manually can quickly become overwhelming. It becomes a huge task to manage and define permissions for each employee. A minor error can lead to a security breach or any operational issue. 3. **Manual process**: When you configure and define RBAC roles and permissions manually, it can be quite dangerous. Even a small mistake can lead to a security breach. _For example, if an administrator has to permit the developer only to read but mistakenly gives permission to him to write as well, then the developer can modify data, which can lead to vulnerabilities._ 4. **Logs auditing and compliance**: It is necessary to maintain accurate and detailed records for auditing and compliance. To follow standards such as GDPR and HIPAA, you have to maintain detailed logs that show which users performed what actions and when. Kubernetes provides limited tools for RBAC auditing, which makes compliance challenging. ## Approaches to addressing Kubernetes RBAC challenges 1. **Implementing principle of least privilege**: Least Privilege means you have to give minimum permissions to the users they need to do their work. Too many permissions can result in security issues. You should follow the least privilege approach to enhance security. 2. **Policy management tools**: Managing too many policies can be difficult. You can use policy management tools to reduce the burden of managing policies. These tools can create, update, and manage policies for you and ensure RBAC policies are up-to-date and secure. 3. **Namespaced roles**: You should use namespace roles to limit the scope of your resources. With a namespaced role, you can ensure that a user or service only gets access to the resources in that namespace that are necessary for their function. This isolation helps us prevent accidental access. 4. **Auditing RBAC regularly**: You should audit your RBAC configuration regularly. With regular lookups on these configurations, you can timely identify issues and fix them. It's clear that managing Kubernetes access and permissions is quite complex, but it provides a robust security feature at the infrastructure level, and is well worth considering for your future deployments. ## Bring powerful RBAC to your applications Finally, if you're looking to bring that same infrastructure-level power to the application layer, you should check out [Cerbos](https://www.cerbos.dev/). The Cerbos Policy Decision Point (PDP) is a scalable, open source authorization layer for implementing roles and permissions. It can be deployed easily as a sidecar alongside your Kubernetes-managed applications.
[![Cerbos Hub ](https://no-cache.hubspot.com/cta/default/20289770/interactive-181809013399.png)](https://cta-service-cms2.hubspot.com/web-interactives/public/v1/track/redirect?encryptedPayload=AVxigLIsPGsw0kVBfd%2BU5zXB%2F4zjrza4haEsiIWNj0lzsB%2FKVVynt63tVx41mePU0xuZZWXKK1JI6n5kTtblD%2BdJ8jxX0tmI2SlkzFmZz7o8vY%2F4oY%2FGvol3cI5tYLTx80LThtx4Ce0%2BXtshEZG1euH5uGltBdN%2FsIw6sqKALxOUiwAqfTFkXH%2Ff%2FJfG0X7u&webInteractiveContentId=181809013399&portalId=20289770)
## FAQ ### What is RBAC? RBAC stands for Role Based Access Control. It is a method through which we can control access to resources and actions based on the roles assigned to the users. ### When should I use a Role vs. a ClusterRole in Kubernetes? Use a Role for namespace-scoped permissions – for example, giving a developer access to view and edit pods in only the “dev” namespace. ClusterRoles are for cluster-wide permissions that aren’t tied to a single namespace (e.g. granting read access to all secrets cluster-wide or permissions on nodes). If you need the same permissions across all namespaces or on cluster-level resources, go with a ClusterRole (and ClusterRoleBinding); for namespace-specific access, use a Role (with a RoleBinding). ### What are best practices for managing RBAC in large clusters? For large teams and complex clusters, it’s best to adhere to least privilege (give each user minimal rights needed), organize roles by job function, and avoid role proliferation by reusing roles across similar teams. Regularly audit and review RoleBindings and ClusterRoleBindings to clean up unused or over-privileged access. Using policy management tools like Cerbos can help by providing a central view of all permissions. Also, treat RBAC changes as code: use Infrastructure-as-Code templates or GitOps so you can track changes, review them, and roll back if needed.