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.
| ROLE EXAMPLE | CLUSTER ROLE EXAMPLE |
| apiVersion: rbac.authorization.k8s.io/v1 kind: Role Metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] |
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:
| ROLEBINDING EXAMPLE | CLUSTERROLEBINDING EXAMPLE |
| apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role #this can be Role or ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group name: manager # Name is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole #this must be ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io |
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:
Visualize a single default Azure AKS cluster in which no applications are deployed; nor has any application related to role/role bindings been created. This is how a single cluster RBAC relationship appears out of the box:
Figure 1: The complexity of identity within a single GKE cluster, shown here with the sprawling number of overlapping relationships and privileges between subjects, roles, and resources.
This diagram shows the sprawling, interdependent identity relationships of a default single cluster, with each dot representing a resource or user. It’s nearly untenable to manually manage and, even after visualizing the relationships, it’s extremely difficult to easily determine if risky misconfigurations exist.
Uptycs provides multiple options to investigate and detect risky Kubernetes RBAC configurations to eliminate these problems. Once deployed, Uptycs dynamically tracks configurations for overprivileged accounts and risky user rights in real-time.
One solution that has proven especially useful in customer deployments is assessing who can exec into pods. In general, providing “exec into” privilege is very risky in live environments. An attacker can take advantage of this to download/run malicious code, start backdoor containers, et al., before impacting your application and cluster.
Another user case tracks “who can delete k8s events;” attackers discovering a user having this permission can delete Kubernetes logs to erase evidence of their presence and mask lateral movement within your network.
Uptycs finds subjects having risky configurations in these cases and more, making it easy for security practitioners to find the highest priority roles or subjects that require remediation or investigation.
Figure 2: Uptycs unveils which subjects in this AKS cluster have exec privileges, with ‘aks-support’ found to have exec privileges to all resources in the cluster.
Possible Kubernetes 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 Kubernetes 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.
Figure 3: Uptycs investigates specific privileges and resources that subjects are authorized for, here the dashboard tracks and lists all users who can access secretes in the AKS cluster.
Perhaps you want to discover everyone who has ‘get’ access to secrets. Select ‘get’ from the privileges and ‘secret’ from the resource to reveal subjects that can access secrets. From the search result, if the manager group subject shouldn’t have this privilege, you can correct it by creating another role binding.
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.
If you are interested in locking down access to your k8s deployments or looking to implement least privileges across these distributed microservices, reach out below to get in touch and learn how Uptycs is bringing simplicity to the question of who can access what.
Start with our free, no-obligation 35-day trial. Get comfortable with Uptycs using synthetic data, then deploy to a live environment. Get a demo →