Kubernetes RBAC: Concepts, Examples, and Best Practices

Part of the beauty of Kubernetes is that a single cluster can support a virtually unlimited number of applications and users.

However, when you have a plethora of Kubernetes nodes, containers, Pods, and teams sharing the same cluster, things can also become messy and chaotic. Without the right access controls in place, you run the risk that one team might make changes that break another team's app, or that an app hosted in one namespace starts interacting with apps in a different namespace that are supposed to be isolated from it.

Taming this chaos is where Kubernetes Role-Based Access Control, or RBAC, comes in. By providing a native framework for assigning roles and permissions, Kubernetes RBAC helps ensure that every human and non-human user within a Kubernetes cluster can do what he, she or it is supposed to do – nothing more, nothing less.

This article breaks down everything you need to know about Kubernetes RBAC, including how it works, why it's important, and how to use RBAC to help keep your clusters running smoothly.

What is Kubernetes Role-Based Access Control?

In Kubernetes, Role-Based Access Control is a built-in feature that allows admins to assign permissions to users and workloads based on their roles. Using Kubernetes RBAC, you can associate certain types of permissions with certain roles, and then grant roles to human and non-human users who are supposed to receive those permissions. (Non-human users in this context mean software resources that operate within a Kubernetes cluster – so RBAC is not just for controlling the access rights of engineers, but also of workloads and services.)

If you're familiar with Identity and Access Management (IAM) frameworks in public clouds or identity management platforms like Active Directory, Kubernetes RBAC will likely feel similar to you. It works differently in many respects, but the core concept of assigning permissions based on user roles is the same. (To be clear, Kubernetes RBAC is not an alternative to public cloud IAM or Active Directory; on the contrary, each of these types of tools serves different functions. But conceptually, they're similar.)

RBAC vs. ABAC

In Kubernetes, roles serve as the focal point of managing access controls. This makes Kubernetes RBAC different from Attribute-Based Access Control (ABAC), a type of access control framework that grants permissions based on user attributes – such as which department an employee works in or what the IP address of an application is.

There are pros and cons to both approaches. ABAC is often considered more flexible because there is an unlimited range of attributes that admins can use to manage permissions. On the other hand, RBAC is simpler to manage, and tends to be less prone to oversights and mistakes, because access rights are mapped onto predefined roles.

A full discussion of RBAC vs. ABAC is beyond the scope of this article, but suffice it to say that Kubernetes opts for an RBAC approach to access control, so that's the one you need to know if you work with Kubernetes.

Why is Kubernetes RBAC important?

Kubernetes RBAC is important because it helps ensure that every user and workload has the permissions it needs to do its job, without having additional rights that could create security or privacy issues.

Again, being able to assign rights based on roles is especially important in Kubernetes because it's common for an organization to set up just one Kubernetes cluster, and then use it to host all of the cloud-native workloads that the organization deploys. This means that many apps and users may share a single cluster, making it critical to have a way of controlling who can do what.

Without RBAC, you'd run into situations where one team of developers could modify other teams' applications, or where resources that should be available only to certain applications are accessible by others. This increases not only the risk of intentional harm caused by malicious actors inside an organization, but also the chances that one person or service will make changes that inadvertently disrupt resources "owned" by another person or service.

With RBAC, however, lots of users and apps can share the same cluster in a coordinated, low-risk way.

Benefits of RBAC in Kubernetes

By providing a systematic way of managing user rights and permissions, RBAC provides several key Kubernetes benefits:

• Granular access control: With RBAC, each user can receive exactly the right level of permissions. This granular approach avoids situations where some users receive more permissions than they require because they are lumped in with other users within a blunt access control framework.
• Improved security: Along similar lines, RBAC improves security by helping organizations avoid assigning unnecessary privileges to users. The less each user can do, the lower the potential harm the user can cause (or attackers can cause if they manage to compromise the user's account).
• Access auditing: On its own, Kubernetes RBAC doesn't audit access controls, but it can be used in conjunction with the Kubernetes auditing feature to track who is doing what within clusters. This is because RBAC provides a central way of defining identities and access events.

How does RBAC work in Kubernetes?

Kubernetes RBAC works by allowing admins to define roles and permissions associated with them, and then "bind" those roles to users or groups.

Roles are defined using the following API server objects:

• Roles, which grant permissions that apply only within a particular namespace.
• ClusterRoles, which grant permissions that apply throughout an entire cluster (i.e., across multiple namespaces).

For example, you could configure a Role like the following, which grants permission to get a list of Pods running in the namespace named default:

To assign the permissions associated with a role to specific users, you would use one of the following:

• RoleBinding, which assigns the permissions within a specific namespace.
• ClusterRoleBinding, which assigns the permissions across the entire cluster.

For example, the following RoleBinding assigns the pod-get Role (which was defined in the example above) to a user named admin.

Basic concepts of K8s RBAC

Now that we've covered the basics of how Kubernetes RBAC works, let's dive a bit deeper by exploring some of the key technical concepts at play.

Verbs for permission management

Kubernetes RBAC relies on "verbs" to define the specific permissions associated with a role. Examples of verbs include get (which grants permission to list or view resources), create (allowing the creation of new resources), and delete (which, of course, lets you delete resources).

This approach means that there is a finite set of predefined permissions available – which limits the flexibility of the RBAC Kubernetes framework to some extent, but which also helps to keep permissions predictable and organized. If permissions were totally open-ended, different admins or teams would likely end up implementing different types of permissions, leading to conflicts and inconsistencies.

Aggregated ClusterRoles

If you need to add new permissions to an existing role, you can do so using ClusterRole aggregation. Aggregation allows you to define additional permissions for the role (using the verbs described above) without modifying the role itself.

User accounts vs. service accounts

As we mentioned, RBAC in Kubernetes supports both human and non-human users. Roles and permissions for humans are managed via user accounts, while service accounts are used for non-human users.

In most other respects, there are no differences between each type of user. Roles and permissions for both types of user are assigned in the same basic way, and both can access the same permissions. But depending on which category of user you're working with, you'll need to create either a user account or a service account.

Role and ClusterRole bindings

Kubernetes RBAC imposes a strong differentiation between the process of configuring roles and permissions, and the process of assigning permissions.

As we said above, you create a Role or ClusterRole to define permissions. However, no users actually receive those permissions until you bind them using a RoleBinding or ClusterRole binding. This separation helps ensure that no one receives permissions until the permissions have been fully configured, because permissions are not granted at the same time as they're set up.

Namespaced vs. non-namespaced Roles

In Kubernetes, access controls can be defined either within a particular namespace (using Kubernetes Roles and RoleBindings) or across a cluster (using ClusterRoles and ClusterRolesBindings).

This approach makes sense given that it's common for organizations to set up different namespaces for different teams. Each team can use Roles and RoleBindings to manage permissions for resources in the namespace it manages. At the same time, however, cluster admins who need to work with the entire cluster – or software resources that operate across the cluster – can receive the permissions they require using ClusterRoles and ClusterRolesBindings.

Common RBAC misconfigurations and mistakes

Like most Kubernetes features, RBAC is powerful, but it can also be complicated to use. You may make mistakes or misconfigurations that trigger issues like the following.

Aggregation permissions across duplicate Roles

It's possible to bind multiple Kubernetes Roles (or ClusterRoles) to the same user. If that happens, Kubernetes aggregates the permissions – meaning the user receives all of the permissions granted across all of the roles. It doesn't default to using only the most recent Role or granting permissions that are part of both Roles.

In general, this isn't desirable because it creates a risk that a user will have permissions you didn't know about, because you mistakenly believe that the user has just one Role - but in reality, an additional Role exists that grants additional permissions.

You can check for duplicate roles by running this command (being sure to specify the appropriate namespace name):

You can then delete duplicate roles using:

Retaining unused Roles

Keeping Roles active after they're no longer necessary is another common RBAC mistake in Kubernetes. This is a risk because it keeps permissions available that are not necessary, violating the principle of least privilege.

Unfortunately, Kubernetes doesn't provide any native features for finding unused roles (although some distributions have add-on capabilities for this purpose). The best way to detect Roles that are no longer in use is to examine the API server logs and compare activity against lists of Roles that remain in force. Roles that haven't seen any activity are candidates for deletion.

Conflating Roles with ClusterRoles

Since ClusterRoles grant permissions across an entire cluster, it can be tempting to create a ClusterRole to avoid the inconvenience of having to specify namespace when managing permissions (or having to create multiple Roles for different namespaces).

This is not a best practice, however, because it leads to unnecessary permissions. You should only create ClusterRoles in situations where cluster-wide access is truly necessary. Don't use them as a convenience for assigning permissions to users or services that need to work within some, but not all, of your namespaces.

Kubernetes RBAC troubleshooting

If K8s RBAC is not working as expected, the first thing to do is assess whether you're having an issue with certain Roles or ClusterRoles, or with all of them. In the latter case, you likely have a problem with the way your API server is configured.

Or, if you're using a Kubernetes distribution that integrates with an external IAM framework (for example, if you're running Amazon EKS), it's possible that conflicts between IAM and the internal RBAC Kubernetes framework are the root of your issue. You should check your distribution's documentation to understand how external IAM integrations work. EKS monitoring and similar solutions might help, too. 

To troubleshoot Role-specific problems, start by using the following command to list Roles and RoleBindings you've configured:

(The syntax for inspecting ClusterRoles is identical, except clusterrole replaces role within the commands.)

Make sure that all of the Roles and RoleBindings you expect to be present are actually available. You may find, for instance, that you created a Role but forgot to bind it, which is why RBAC is not working.

To dive deeper, you can use these commands to get details about a particular Role or RoleBinding:

You can also check the API server logs (which are typically located at /var/log/kube-apiserver.log) for additional context on RBAC events.

Challenges in Kubernetes Role-Based Access Control

Managing RBAC effectively in Kubernetes can be challenging for a number of reasons.

Complexity and scalability

Although the fundamental concepts behind RBAC are simple enough, the code for RBAC policies itself can be complex. So can the process of writing and binding multiple policies across multiple namespaces. And unfortunately, Kubernetes has no built-in tooling to help automate or scale these processes.

Lack of Role auditing

Kubernetes also offers no native tools for assessing Roles and validating that users are receiving appropriate permissions. Some third-party tools are available for scanning permissions settings, but even if you use those to help audit roles, you'll need contextual awareness into what each user is supposed to be able to do. No tool can determine on its own whether your settings are appropriate because tools don't know exactly what your users actually do.

Lack of holistic Role monitoring

Beyond using kubectl to list or describe Roles and RoleBindings, Kubernetes has no central feature for monitoring all policies or how they are being used. You can use audit logs to track access events, but that's different from monitoring your actual policies.

Kubernetes RBAC best practices

To use RBAC in Kubernetes to maximum effect, consider best practices like the following:

• Keep Roles granular and precise: While it's more work to set up multiple Kubernetes Roles, it's better from a security standpoint to create granular, precise Roles that are assigned to individual users, rather than trying to cover the needs of multiple users through a single Role.
• Enforce least privilege: When creating Roles, assign verbs that grant the fewest privileges necessary to support an intended use case. You can always add more permissions later if you need to.
• Minimize wildcard use: K8s RBAC supports the use of wildcard characters in some contexts. These can be convenient, but avoiding them is a best practice because wildcards can have unintended consequences. They may match with users you didn't intend, leading to excess privileges.
• Review and remove unused Roles: As noted above, you should compare lists of active RoleBindings to active users, then remove bindings for Roles that are no longer necessary.
• Manage RBAC policies using IaC: If you define all of your RBAC policies in a consistent way and store your code in a central repository, you can take an Infrastructure-as-Code (IaC) approach to RBAC management. This means automatically defining and applying policies from a central location. IaC also helps enable Role scanning – which, again, is not something Kubernetes supports natively, but third-party tools are available for auditing Roles.

Kubernetes RBAC with groundcover

While groundcover isn't a Kubernetes RBAC management tool, we provide the visibility and context teams need to troubleshoot RBAC issues effectively. When you need to know quickly if performance issues in your cluster are linked to RBAC problems, groundcover's Kubernetes monitoring capabilities provide critical clues by comprehensively tracking what's happening across your cluster as a whole, as well as within specific workloads.

Why we love Kubernetes RBAC

There's no denying that RBAC in Kubernetes can be complicated. But it's also crucial for any team that wants to manage clusters responsibly. Once you get a handle on how RBAC works and understand how to troubleshoot common issues, you'll be able to share your cluster with as many users and workloads as your heart desires, creating a single platform to serve all of your cloud-native needs – which is probably one of the reasons why you're using Kubernetes in the first place.