Identity is at the heart of protecting infrastructure, but making sense of alert noise can be difficult—especially in dynamic k8s environments. Kubernetes’ highly distributed nature creates complexity around who, from an identity standpoint, can access what resources. 

Binding prescriptive roles to specified subjects (i.e., users, service accounts, and groups), role-based access control (RBAC) is a security model used to manage access to resources. RBAC offers a granular and flexible approach to managing permissions for subjects; it’s a highly centralized model explored in depth in this blog post.

RBAC oversees access to k8s resources such as pods, services, and config maps. The number of microservices means the collection of roles and subjects is nearly impossible to track manually, and misconfigurations can easily slip by unnoticed. 

By building on the k8s API, RBAC implementation provides a more dynamic and unique resource model. Network administrators have more granular control over roles and scope of access than ever before.

Two role categories exist in Kubernetes: role, which provides access to namespace objects, and ClusterRole that provides access to cluster-wide objects. This creates a layered approach between either specific resources or cluster-scoped access. 

In the Role example above, subjects with a ‘pod-reader’ role have the privilege of accessing “get/watch/list” pods in the ‘default’ namespace. This role provides access to the mentioned namespace objects only. You don’t have to include a namespace using ClusterRole; the “secret-reader” role allows subjects to “get/watch/list” secrets across the cluster. 

These two role categories are assigned to a subject using a k8s object called RoleBinding or ClusterRoleBinding. Admins use RoleBinding to limit user access to namespace resources only, while a ClusterRoleBinding provides access to cluster-wide resources. 
Here are RoleBinding and ClusterRoleBinding examples: 

In the RoleBinding ‘read-pods’ example above on the left, we bind the subject ‘Jane’ with the ‘pod-reader’ role in the default namespace, whereby she can get/watch/list pods in that realm (note that namespace is specifically mentioned when using RoleBinding). 

Using ClusterRoleBinding above on the right, ‘read-secrets-global’ binds a ‘manager’ group with ‘secret-reader’ privileges. Members of those in the ‘manager’ group can now get/watch/list secrets to an entire cluster. 

Three kinds of subjects can have roles assigned to them: users (e.g., developers, admins), service accounts (think of them as pod identities), and groups (groups of users or service accounts). Permutations that combine disparate subjects, roles, role binding objects, and resources makes access management extremely complex at scale. 

Before you even start your initial application deployment, k8s clusters have a high number of cluster roles, cluster role bindings, and service accounts by default. At the same time, there is no out-of-the-box Kubernetes tool to visualize the RBAC model implemented within a cluster. To understand RBAC relationships, admins manually parse each Role/ClusterRole, RoleBinding/ClusterRoleBinding using a k8s CLI to find misconfigurations. 

Imagine a user accessing a resource they shouldn’t have permissions for, or who is able to arbitrarily create privileged pods. As a practitioner, you know that such misconfigured RBAC models within k8s deployments provide gaps for attackers to take advantage of. 
But the biggest question persists—how can you easily uncover RBAC misconfigurations in complex k8s systems? And how do you gain clarity to this interlocked system of k8s identities? 

Uptycs K8s Access Monitor—part of our KSPM offering—addresses these pain points for parsing RBAC configurations, thereby enabling you to truly understand identity risk at runtime. 

K8s Access Monitor solves two use cases:

Possible RBAC misconfigurations exist with every new application being deployed. Auditing helps you detect if a subject has certain privileges that aren’t needed, or if a subject shouldn’t have access to a k8s resource. Such regular auditing finds such misconfigurations and assists you in maintaining the least privileged RBAC model. 

To help with auditing, Uptycs investigates resources and tracks roles and subjects that can manipulate resources. This starts with malicious actions, while also offering the flexibility to flip the script. That is, you can select a specific subject to investigate their privileges and resource relationships.

Uptycs audits your RBAC relationships, making it simple to correct misconfigurations and manage the complexity of Kubernetes identities. Auditing regularly and removing risky configurations helps you maintain the least privilege model while also reducing the attack surface. Even if an attacker infiltrates a k8s pod, hardened RBAC prevents them from moving laterally within your network or accomplishing much else. And it helps in preventing unintentional changes by removing unnecessary privileges from subjects.