Visualizing RBAC for Improved Security Management and Outcomes

RBAC management is crucial to securing a Kubernetes cluster and ensuring compliance with regulations and industry standards. ARMO Platform includes an RBAC visualizer allowing administrators to see which privileges are assigned to any given user.

Role-based access control—commonly known as RBAC—is the practice of assigning access to an organization’s resources whereby the level of access privilege depends upon an individual’s role in the organization. Our deep dive on the basics of RBAC in Kubernetes is the best place to get started if you’re new to the topic.

RBAC in Kubernetes is essential to ensuring the security of an organization’s infrastructure. Unfortunately, one of the main issues with RBAC implementation is that it is challenging to maintain and visualize. In this article, we’ll discuss why RBAC is a burden for most administrators to maintain and visualize by first looking at two implementation scenarios, then delving into the problems that arise, and finally examining how visualization would improve the process.

Steps to Implement RBAC in a Cluster

Let’s take a look at two basic examples of implementation of RBAC in a Kubernetes cluster. 

Scenario 1: RBAC on an End User Accessing the Kubernetes Cluster

Let’s say we have a user named John, who only needs read access to pods in a namespace called “staging.” Before even creating the kubeconfig file for John, certificate generation needs to be performed. Then, we can go ahead and create John’s kubeconfig, as well as his role. Let’s call the role staging-pod-reader. Run this YAML file to create the role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: staging-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

In order to associate the staging-pod-reader role to John, a role-binding needs to be created. Here’s the code for that:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: staging-pod-reader-role-binding
  namespace: staging
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role 
  name: staging-pod-reader
  apiGroup: rbac.authorization.k8s.io

From here on in, both the files need to be maintained in order to revoke or update access for the future users.

Scenario 2: RBAC on a Pod Running in a Kubernetes Cluster

Whenever a pod is created, Kubernetes associates a default service account with that pod, which comes with particular permissions. Best practice dictates that we associate service accounts with custom permissions while deploying a pod. Let’s try to create a service account called staging-secrets along with a role named staging-secrets-read. We want any pod with this role to only read secrets within the staging namespace. First, create the service account:

kubectl create serviceaccount staging-secrets -n staging

Follow the same steps as in scenario one (above) to create a role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  Namespace: staging
  name: staging-secrets-read
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Next, create a role-binding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: staging-secrets-read-role-binding
  namespace: staging
subjects:
- kind: ServiceAccount
  name: staging-secrets
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role 
  name: staging-secrets-read 
  apiGroup: rbac.authorization.k8s.io

Once the role is created, and has been associated with the service account, we can create pods with the staging-secrets-read service account.

Problems with RBAC

As we’ve seen, implementing a single RBAC control in a single cluster involves a number of manual steps, such as creating a subject, and creating a role with resources and verbs. Unfortunately, this is the only way to implement RBAC in Kubernetes.

In reality, an organization in production will have many clusters, resources, and users, each with various (and potentially individualized) access. According to VMware’s State of Kubernetes report 2022, the majority of organizations run six or more clusters, with 29% running upwards of fifty! Thus, a major problem with RBAC management emerges: it is not easily scalable.

Role Explosion

As mentioned previously, RBAC needs to be fine-grained in order to serve a large pool of users and roles within an organization securely. For example, while some engineers might need read-only access, others might need write access sprawling across clusters. As a result, you cannot create an engineer role and be done, because not all engineers can be given the same access permissions. When it comes to creating and distributing roles, administrators may forget who is assigned to each role within the many clusters.

This leads to a phenomenon known as role explosion, which refers to a rising in the complexity of the role structure over time. When so many roles are created within an organization, a number of problems can arise: Administrators may have a hard time keeping track of the privileges assigned to each role; roles created for temporary purposes may be forgotten; and errors—such as someone being over-privileged—may occur.

Complexity and Scalability Challenges

Kubernetes is a highly flexible and scalable platform for managing containerized applications. Still, the complexity of the relationships between different roles and permissions within a cluster can be challenging to understand.

As the number of roles and permissions grows, especially in a production environment with multiple clusters, the difficulty in comprehending the impact of changing a role or permission on the overall access control system increases exponentially. This is because Kubernetes doesn’t provide a native solution to manage and synchronize RBAC policies or to keep track of access-level changes. Furthermore, administrators have only a handful of kubectl commands to retrieve information about the roles, cluster roles and role bindings. Resulting in only a small part of the big picture. As a result, dealing with hundreds of roles makes management a challenging, time-consuming, and error-prone process.

How Does RBAC Visualization Help?

A visualizer tool can be highly beneficial in addressing the challenges posed by role explosion in a Kubernetes cluster. By providing an intuitive and graphical representation of the relationships between roles and bindings, a visualizer can help administrators to:

• Understand complex access control policies: A visualizer helps administrators to make sense of the complex relationships between roles and bindings in a Kubernetes cluster. By presenting these relationships visually, administrators can better understand the granted access control policies. Thus make informed decisions about policy changes. This feature is beneficial when protecting the your Kubernetes environment from becoming a growing attack surface.
• Clean up temporary and unused roles: Administrators can benefit from visualizers in order to identify temporary and unused roles that were created in the past but are no longer necessary. By removing these roles, administrators can help to reduce role explosion, which makes it easier for them to manage the remaining roles and bindings. Removal of unused accounts also protects them from becoming targets of malicious actors.
• Identify problems with access control policies: A visualizer can help administrators identify contradictions in access control policies. For example: where access is granted to a resource group or specific resources and this inherited access contradicts the explicit access given to specific resource. By bringing these issues to light, administrators can make changes to the policies to resolve the problems and ensure that the access control system is functioning as intended.
• Identify over-privileged resources: A visualizer can make it easier to identify users who have been given too many privileges. When administrators can identify these users, they can reduce their privileges to a more appropriate level. This is especially helpful in organizations that adopted the easy path of giving everyone administrative privileges, which contradicts security best practices. By doing this, administrators can promote the principle of least privilege, which is the recommended and more secure approach.
• Streamline the onboarding and offboarding process: A visualizer can make managing users’ onboarding and offboarding process and user access to resources easier for administrators. By providing a clear representation of the roles and bindings associated with each user, administrators can quickly and easily make changes to the access control policies when a user joins or leaves the organization.

In summary, a visualizer tool can significantly benefit organizations managing Kubernetes clusters by providing a clear and concise representation of access control policies, assisting with identifying and resolving issues and streamlining the management of user access to resources.

Conclusion

RBAC management is crucial to securing a Kubernetes cluster and ensuring compliance with regulations and industry standards. However, without the proper tools in place, managing RBAC can be a complex and error-prone manual process. This is why RBAC visualization is essential. Visualizing RBAC helps administrators to keep track of all privileges in a systematic and organized manner. A visual representation of the relationships between roles and bindings allows administrators to understand the policies more easily, and thus make informed decisions about policy changes. RBAC visualization is critical to securely managing Kubernetes in production and ensuring security and compliance.

ARMO platform includes an RBAC visualizer allowing administrators to see which privileges are assigned to any given user. With ARMO Platform, administrators can take control of RBAC management and reduce the attack surface by conforming to the principle of least privilege.

Unifying AppSec, CloudSec and DevSec

The only runtime-driven, open-source first, cloud security platform:

Continuously minimizes cloud attack surface

Secures your registries, clusters and images

Protects your on-prem and cloud workloads

Powered by Kubescape & eBPF

See ARMO in Action