Kubernetes RBAC: Role-Based Access Control

Contents

What is Kubernetes RBAC?

RBAC Vs ABAC

The role of RBAC in authentication and authorization

How do you authenticate to a Kubernetes cluster? 

The role of RBAC in fortifying Kubernetes security

How to secure RBAC authorization

How Kubernetes context and RBAC work

What is “Security Context” in Kubernetes? How does it differ from Kubernetes Context?

Kubernetes RBAC Best Practices

Kubernetes Top 5 Overpermissions

K8s RBAC Tools Comparison for Posture Management

Krane

KubiScan

Kubescape

Rbac police

Detailed RBAC Kubernetes Tool Comparison Table

How RBAC factored into the Kubernetes attacks of 2023

Most frequently observed RBAC security risks

KSOC secures Kubernetes RBAC with cloud native identity threat detection and response (ITDR)

Riskiest identities

Beyond posture into actual identity usage

Right-sizing

Conclusion

What is Kubernetes RBAC?

Kubernetes Role-Based Access Control (RBAC) is a method of controlling who can access the Kubernetes API and what actions they can perform across the cluster. It is the broadest authorization mode into different parts of Kubernetes, making it a critical part of your overall Kubernetes security strategy. 

Security breaches can start with overly permissioned Kubernetes roles, but Kubernetes does not provide easy management for RBAC roles, so practitioners are left to navigate and manage it on their own with a slew of third party tools. By the end of this blog, you should have a better understanding of the meaning, and classic over permission like, for example, assigning Kubernetes cluster roles. 

Kubernetes Role-Based Access Control (RBAC) functions as authorization that governs who can do what within your Kubernetes clusters. A policy consists of information specifying a collection of the following:

At first glance, Kubernetes has what appears to be a surprisingly thin concept of a “user.” Users don’t have a unique file system (i.e., a home directory) like on an operating system or a distinctly managed “account” as in many applications. There is not even a defined API object in Kubernetes for a “user.” This it turns out is an intentional choice to outsource provisioning and authenticating user accounts in deference to whatever system you use already for identity management. You can read more about this in the first part of our series on Kubernetes Security Posture Management.

Once you have authenticated, however, the authentication material becomes part of what is recorded in the Kubernetes context: a certificate to present to the cluster, a user token, etc. The appropriate authentication material is then presented to the Kubernetes API, which validates it as genuine and then grants access in accordance with whatever relevant RBAC policies may apply.

That is because while Kubernetes does not have an object for users, it is aware of user identities and they can be bound, through (Cluster)RoleBindings to particular (Cluster)Roles. This allows the permissions of users to be appropriately scoped and limited based on their access needs and requirements.

When you create a service account or a user, you’re defining:

• What Kubernetes resources the user has access to
• What Namespaces the user has access to
• What nodes the user has access to
• What they can do in that resource

The way you do this is with “roles” and “clusterroles” that are allowed specific permissions, and applied to users through rolebindings. 

For example, here is a basic (and very insecure) RBAC role that says, “The pod-reader role has wildcard access and get, watch and list permissions for resources in the dev-group-1 namespace.”

RBAC vs. ABAC

There are other ways to authorize a request to the API server besides RBAC; namely Attribute Based Access control (ABAC), Kubelet and Node authorization. 

Kubernetes ABAC authorization grants access based on attributes, like user attributes, resource attributes, or environmental conditions. 

Kubelet authorization provides additional protection by only allowing specific operations on the node, such as launching new containers or modifying existing ones. Kubernetes node authorization is an important part of Kubelet authorization, authorizing API requests made to kubelets. 

RBAC uses predefined roles assigned to users to manage permissions, making it simpler and more straightforward than other methods of managing permissions. For the purposes of this article, we will focus on the ins and outs of RBAC.

The role of RBAC in authentication and authorization

Before we dive deep into the details of RBAC, it’s important to understand its role in overall authentication and authorization into Kubernetes. Below is a diagram of a request flow to the Kubernetes API server. In this article we will be discussing authentication and authorization, as admission control is a relatively larger topic on its own.

The requests to the Kubernetes API server will come from a user (a person), a Service Account, or some other ‘thing’, basically from one API to another. The steps for these requests follow the flow:

• Authentication: Does the user/machine have the right credentials to access the API server? This is usually taken care of by Cloud Identity and Access Management
• Authorization: What is this authenticated user/machine allowed to do?
• Admission control: Is this type of workload ok to be scheduled, based on a set of parameters and policies we want to enforce?
• Etcd is then involved in holding the configuration data, state data, and metadata that would allow for persistence of this set of parameters 

The requests to the Kubernetes API server will come from a user (a person), a Service Account, or some other ‘thing’, basically from one API to another. The steps for these requests follow the flow:

1. Authentication: Does the user/machine have the right credentials to access the API server? This is usually taken care of by Cloud Identity and Access Management
2. Authorization: What is this authenticated user/machine allowed to do?
3. Admission control: Is this type of workload ok to be scheduled, based on a set of parameters and policies we want to enforce?

Etcd is then involved in holding the configuration data, state data, and metadata that would allow for persistence of this set of parameters 

How do you authenticate to a Kubernetes cluster? 

If authentication is left to Cloud IAM, then how exactly do you authenticate into a Kubernetes cluster, and how is RBAC involved? 

Here we have a flow diagram with the following steps, using the example of Amazon’s managed kubernetes platform, EKS:

• First, the person or the machine (API) will present a Cloud IAM token and authenticate to AWS.
• The person or machine then says, ‘I want to take an action (for example, kubectl get pods all namespaces)’, and present this request to the Kubernetes API server
• The Kubernetes API server will then pass the Cloud IAM token to the aws-iam-authenticator-server, which is installed as a daemonset on the workload cluster
• The aws-iam-authenticator-server is responsible for talking to AWS to determine whether the Cloud IAM token is valid, and the response it gets from AWS is an IAM Identity
• This IAM Identity is then passed to the aws-auth ConfigMap. It’s job is to translate the IAM Identity into a Kubernetes subject. This is an important step, because AWS doesn’t speak native Kubernetes
• The Kubernetes subject is then passed back to the API server, combined with your original request (e.g. kubectl get pods all namespaces)
• RBAC then responds with a yes or no, this person/machine can or cannot take this action

At this point, it should be clear that authentication is performed by Cloud IAM. The difference between RBAC and Cloud IAM is that Cloud IAM is a much broader framework provided by cloud service providers. It governs access to various cloud resources beyond Kubernetes, such as virtual machines, databases, and storage. While Kubernetes authorization specifically focuses on controlling interactions within the cluster, IAM operates at the cloud infrastructure level, allowing administrators to manage access across multiple services and resources within the entire cloud environment. 

The role of RBAC in fortifying Kubernetes security

At this point, after just a short introduction to RBAC, it is possible to see how RBAC could be the most important key to Kubernetes security. There is a reason that RBAC over permissions are included in the Kubernetes OWASP Top 10 as one of the top ten Kubernetes risk factors. But how easy is it to get access to your RBAC permissions, or for an attacker to use them to their advantage? 

When a user is assigned permissions, those permissions are embedded into the users Kubeconfig, which is essentially the file that sits on your local computer, giving you the capability to authenticate to ‘x’ Kubernetes cluster. The Kubeconfig is not encrypted and it sits in a directory on your computer that is not necessarily hidden.

If you have full-blown admin/root access, what happens when a bad entity gets a hold of that Kubeconfig? A recent software supply chain attack found attackers actively searching for the Kubeconfig file, showing just how aware attackers are regarding this treasure trove.

Securing RBAC (and finding a secure place for your Kubeconfig file if you are an admin) is, in short, one of the top, if not THE top mitigations against possible attacks on your clusters. 

How to secure RBAC authorization

Understanding what RBAC is and why it’s important in Kubernetes is step one. Step two is figuring out how to mitigate as much risk as possible in your Kubernetes cluster with proper RBAC configured. The reality is that you cannot mitigate every single security breach that could occur. It’s simply not possible. However, you can take the proper steps and precautions to mitigate as much as possible.

First, you want to set a standard for your team and organization. Very rarely does technology solve people problems, and it never solves security issues across teams. The first step is to ensure that the team you’re on, the teams you’re working with, and management understand why RBAC is important, why it should be a key focus, and set a standard for everyone across the teams.

Second, you want to ensure that the least privilege is always the first thing that comes to mind when configuring RBAC. Much like every other sector of tech, you don’t want to start by giving everyone full-blown access and take away the access as needed. Instead, you want to give everyone (and every service account) the bare minimum that’s needed. Then, as issues arise, give more permission to suit the needs of whatever is occurring.

Third, ensure you understand what you’re installing. Many Kubernetes platforms and tools have to interact with your Kubernetes cluster. For them to interact with your Kubernetes cluster, 9.999999 times out of 10, the tool/platform is giving you a Kubernetes Manifest or Helm Chart to run on your cluster. This Manifest contains a whole bunch of goodies, including (usually) a service account creation and RBAC bindings. If you look deep enough into what might feel like one million lines of YAML, you’ll notice that a lot of these tools/platforms are giving FULL root/admin access to the service accounts. 

This kind of third party access was called out this year in a CubeFS CVE . In Kubernetes, CubeFS is used for data processing services and machine learning. The CVE states that the DaemonSet used for installation relies on a cluster-role called cfs-csi-cluster-role which has the following RBAC configuration, and is too permissive.

So for third party resources, you have to ask yourself “is this actually needed?” and if it is, figure out why and how to remove the need. Sometimes it’s possible, sometimes it’s not. Again, you can’t mitigate all risks, but you can certainly ensure you understand the risk.

How Kubernetes context and RBAC work

We often talk about the importance of Kubernetes Role Based Access Control (RBAC) for maintaining the Principle of Least Privilege in your Kubernetes cluster. There are two potential complications to an RBAC implementation that we haven’t discussed, however. 

First, how do your Kubernetes admins/developers/users assume an RBAC defined role in your cluster? 

And second, how do you manage such roles across multiple clusters or when users may need multiple roles in the same cluster? In other words, how do you do identity management in Kubernetes?

Luckily, Kubernetes has a single concept that answers both of these questions: “Context.” 

Kubernetes is designed to enable you to access multiple clusters simultaneously. You can also have multiple “identities” in the same cluster. You may have local Kind or K3s clusters on your laptop used for development plus test, staging, and production clusters hosted in the cloud, for example. When you type in a kubectl command it needs to know which cluster to send that command to, and this is where “context” comes into play. 

Kubernetes context can be thought of as a profile defining a cluster, its location, how to authenticate to it, and what namespace to use. To switch between defined contexts is as simple as running kubectl config use-context context-name.Because it is easy to switch contexts with a single command, users who sometimes require elevated permissions can still perform day-to-day operations with less privileged access and elevate their permissions only when necessary.

What is “Security Context” in Kubernetes? How does it differ from Kubernetes Context?

Kubernetes security context refers to the permissions attached to the processes running in your pods. 

Security Context can be used to specify things like the numeric identity of the “user” (in the container) processes run under, assign certain Linux capabilities, or attach SELinux labels. Security context can be assigned at the pod or container level. It has a role to play in the overall permissions architecture of your cluster, but it operates in a somewhat different plane than RBAC, focused on the inner workings of your deployed applications rather than their permissions to access other resources in the cluster.

It is relatively easy to follow the Kubernetes security best practice of operating day-to-day under a more restricted set of permissions (ideally read-only) using context. If/when the need arises for a user to expand their access, it is quite easy to switch roles by adopting a new context:

kubectl config use-context new-role

This new context just needs to identity a new “user” by supplying a different certificate or token, for example. Once that new authentication material is validated the API will grant access to whatever permissions are specified in the (Cluster)Roles bound to that new user identity.

Kubernetes RBAC Best Practices

To make your Kubernetes RBAC journey easier, we have sifted through best practices guides from industry organizations and individual researchers for the best ways to avoid over-permissions. Combining top best practices from trusted sources such as OWASP Kubernetes Top 10, Kubernetes.io, and individual researchers, the tips also reference 15 specifics to pay attention to in terms of verbs, major gotchas, and permissions that beget other permissions. 

Examples of Common RBAC Misconfigurations and Security Risks 

RBAC policy examples will help to demonstrate what would constitute overly permissive settings. 

A ClusterRole is a role that applies cluster-wide. In the policy below, it says that the ClusterRole can use get, watch and list verbs and view secrets for your resources in the dev-group-1 namespace.

Rolebinding, and in this case, ClusteroleBinding is a way to apply role or ClusterRole permissions to a user or machine.

In the example below, the user Jane is now bound to the role named ‘pod-reader’, so she can do anything that is allowed in the pod-reader role. As we learned above, the pod-reader role has wildcard access and get, watch and list permissions for resources in the dev-group-1 namespace.

Let’s now go through the whole process from start to finish, creating an RBAC policy using a serviceaccount. 

First, you’ll want to create a service account. As a reminder, a service account is a type of ‘machine’ user, or an abstraction that allows a machine to make an API call to the Kubernetes API server versus a person. This is quite common, as there is a lot of machine to machine communication within Kubernetes. Just like a user that is an actual person, a serviceaccount allows access to specific resources. As such, you can set up a user (like yourself) as a service account or you can set up a service account that’s used for Pod creation.

The service account Manifest below creates a new service account called “mikeuser”.

apiVersion: v1kind: ServiceAccountmetadata:  name: mikeuser

Next, you have to set up some permissions for the service account. Although the service account isn’t defined in the below Manifest, the below Manifest is creating the permissions that the “mikeuser” service account should have. In this case, you’re giving “mikeuser” authentication to the Pods Kubernetes resource. Then, you’re giving it authorization to Pods to do the following:

• Get
• Watch
• List

This means you’re giving “mikeuser” authentication access to Pods and authorization to perform read-only actions.

kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: readerrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "watch", "list"]

After you define the ClusterRole and the permissions that you want the “mikeuser” service account to have, you can bind the service account and the Role together with a ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: read-pod-globalsubjects:- kind: ServiceAccount  name: mikeuser  apiGroup: ""  namespace: defaultroleRef:  kind: ClusterRole  name: reader  apiGroup: rbac.authorization.k8s.io

You may see other configurations that show “Role” instead of “ClusterRole” and “RoleBinding” instead of “ClusterRoleBinding”. The difference is whenever you see “Cluster” in the Kubernetes resource, the permissions/authentication/authorization you’re giving a service account is cluster-wide, not node specific.

This example highlights a common gotcha; generally, we want to avoid creating clusterroles and clusterrolebindings and instead use more specific, scoped roles and rolebindings. Cluster roles and cluster role bindings will automatically apply to any namespace you are running, from the kubesystem namespace to the default namespace, or anything else.

Now is the chance to test your knowledge. Can you spot anything wrong with the below YAML? For some background, by default, there is a serviceaccount available by default in every namespace, you can grab it from any pod that spins up.

• In this example, we’re looking at the service account located in the default namespace
• The service account is bound to the cluster role named ‘cluster-admin’
• If you were to have a web app running in the default namespace, and you’ve mounted this service account into every pod, if somehow remote code execution happens or somebody gets access to the file system, they are now cluster admin, creating a huge blast radius
  
  

Kubernetes Top 5 Overpermissions

1. Pay attention to defaults

If you have a small cluster with a few nodes and a few team members can you just use the default settings? RBAC in Kubernetes comes with default settings that may open you up to excessive permissions. For example, if you don't remove bindings from the system:unauthenticated group, any of those bindings can allow anonymous users to contact the API server via the network. Another example is the automountServiceAccountToken setting, which you will want to set to :false so that your service account tokens are not mounted by default.   

2. Organize your roles 

Many RBAC over permissions issues can be caused by roles that are easy to lose track of.

Role aggregation 

Role aggregation adds an efficient method of combining new privileges into existing roles. However, when this is done, it must keep the intended use of the original role in mind. If you only want a role to have read access, any other role that is aggregated must not have access that goes beyond this. It sounds simple, but the point is to carefully review the privileges of the roles involved before performing role aggregation. 

Duplicate roles  

Many roles can grant similar privileges in different ways. Apart from being confusing, if the method of granting privileges is different across roles, when a privilege needs to be revoked it can be ultimately unclear which roles are applicable. Let's use the 'get, list, watch' example from the section below. Perhaps all three of those are being used across two roles. Thankfully using KSOC, we can see which verbs are assigned to the chosen roles below. In the case below, it's consistent across the board, that if one role has get it also has list and watch. It's not the best combination of privileges unless you're a super-admin, but at least there aren't any gotchas. If the user has one of the 3 'big ones' (see below), they have them all, so the policies are consistent.

Unused and missing roles

Roles with missing subjects just make it more difficult to keep track of who should have access to what. Role bindings that reference inexistent roles, could lead to accidental over-permissions if the same role names are used in the future but attached to a different set of permissions. Without an easy query tool, it's easy to see how holes in the completeness of a full RBAC policy can inadvertently lead to accidental over permission. 

3. Look for the big ones: cluster-admin, system:masters, list, get, and watch 

We need to go no further than the OWASP top 10 for Kubernetes to understand the biggest over permissions gotchas with RBAC. 

Cluster-admin

The Kubernetes super user is a cluster-admin, which gives anybody the capability to do - well, anything - in a cluster. The example used in the OWASP guidance details a third-party Kubernetes observability tool that was given cluster-admin access. Unfortunately, this tool's UI was accidentally exposed via a Load Balancer with a public IP address. This means that an attacker could gain access to the Kubernetes API and receive permission to do anything that would help it escalate its privileges throughout the cluster. Generally, a role or cluster role should be created instead of using cluster-admin, and generally, service accounts don't need this kind of access. 

System:masters

Anybody who is a member of the system:masters group is automatically granted cluster-admin access. This is true even if you delete all the roles in the cluster, with no RBAC policies, anybody who is a member of this group gets full access.

list, get, and watch

These three permissions all return equivalent amounts of data, surfacing all attributes of an object versus an object name. The classic use case here is accidentally providing access to a list of secrets. Generally, get is used to allow required access to secrets. But list will also do it, even if get isn't present. The watch permission will do the same except that this continues providing updated information unless it's interrupted. 

4. Beware permissions that beget permissions

Workload creation

It is possible to over permission via the permission to create workloads in a namespace, which carries with it permissions to secrets, ConfigMaps, PersistentVolumes (see below), or even API access levels for any service account in a namespace. This can further lead to privilege escalation and is the reason for the creation of the baseline and restricted Pod Security Standards.

Creating persistent volumes

Granting unrestricted access to create a PersistentVolumein Kubernetes can lead to a security risk because it allows for the creation of hostPath volumes, giving the pod access to the host filesystem on its node. This means it could then escalate privileges across that node using any number of tactics like reading other containers' data or abusing the credentials of the Kubelet. 

To avoid over permissions with a PersistentVolume, only allow access to create PersistentVolume objects to trusted users who need it for their work, such as cluster operators, or to the components responsible for creating a PersistentVolume.

Proxy subresource

If you grant rights to the proxy sub-resource of node objects, for every node they have rights to, you will open up an opportunity for command execution. This is because you are effectively giving rights to the Kubelet API, bypassing audit logging and admission control.  

5. Watch for these verbs

Escalate, Bind, and Impersonate

The escalate verb allows - surprisingly - you to escalate your privileges. Another way of gaining rights to something not already permitted is using the verb bind, which will effectively grant access to the rights of other roles. Another way to accomplish a similar increase in permissions is to use the impersonate verb.

K8s RBAC Tools Comparison for Posture Management

The following list of best practices can help you mitigate Kubernetes RBAC risks and over permissions:

• Scanning RBAC resources across Kubernetes clusters to identify any vulnerabilities or misconfigurations.
• Detecting and addressing Kubernetes misconfigurations that may impact security.
• Identifying and implementing best practices for RBAC configuration and management.
• Generating asset risk reports and ensuring compliance with relevant standards and regulations.
• Implementing necessary remediations to address identified security issues and improve the RBAC security posture

But what are the tools that can help you do this? Kubernetes doesn’t come with these features built-in. There are many open source tools that can help with Kubernetes RBAC posture, by identifying misconfigurations in key Kubernetes components, detecting excessive permissions within roles and user groups, and identifying vulnerabilities that may exploit Kubernetes RBAC resources.

Open Source Kubernetes tools for RBAC 

To analyze these tools’ RBAC capabilities, we used an EKS cluster version 1.24 and used helm as a default installation of the open-source RBAC tools, when this option is available.

• Krane was installed with the v0.1.1 release, using the helm installation. https://github.com/appvia/krane#install-helm-chart
• Kubiscan was installed with the v1.5 release, using the local installation, python.
• Kubiscape was installed with the v2.2.4 release, using the helm installation. https://github.com/kubescape/helm-charts
• Rbac-police was installed with the v1.1.2 release, using the binary installation. 

Krane

Krane is an open source Kubernetes RBAC tool from Appvia, a cloud delivery platform. It works on a rules basis, and you can add your own custom rules. In the chart below, you can see the RBAC index in Krane’s graph visualization. You can consult this data using CypherQL queries. 

After installing Krane in your cluster, it will provide rule-based identification of over permissions along with a mapping all the RBAC components such as wildcard, verbs, impersonate, and missing roles and resources. Other special rules include allowing shell on pods,  allowing viewing specific secrets, a detailed report about subjects with specific verb (delete, read, etc) or  impersonation of privileged groups (like 'system:masters').

Figure: Search by the actor/group/system:unauthenticated

One annoyance with Krane (and many of the other open source tools), is that it contains some noise around the roles and permission of cloud providers (EKS, AKS, etc), which are listed as dangerous issues (see the image below). The cloud providers create their own RBAC resources by default, with roles and permissions, for identity and access management. For example, using an EKS cluster, default ClusterRoles resources such as aws-node and eks:addon-manager are mapped as danger resources in the report. 

Image showing the default aws-node and eks:addon-manager as risky permissions in Krane

The Krane dashboard is helpful, presenting an overview of your RBAC security posture.

Screenshot of Krane dashboard 

KubiScan

Kubiscan is an open-source tool from Cyberark, a security company offering identity management. KubiScan tries to prioritize RBAC risk with the following information and features: 

• Risky pods and containers, mounted volumes, mounted environments variables to pods 
• Pods with access to secret data through environment
• Pods with volume mounted secrets
• Containers with privileged token
• You can search for pods with privileged containers
• An overview about risk users and roles, together with other power controls about secrets, privilege containers, etc.  

The Kubiscan report focuses on privileged service accounts that can be abused to launch privilege escalation attacks. In addition to showing risky permissions to reduce the attack surface, the tool has other nice features such as dump tokens from pods, and shows all pods with access to secret data through a Volume and environment.  

Depending on which version you use, KubiScan might have the same issue around noise for default cloud provider configurations as Krane. 

Screenshot showing pods with access to secret data through a Volume and environment.

Kubescape

Kubescape is an open source tool from Armo that is not only looking for RBAC misconfigurations, but also looking for Kubernetes image vulnerabilities and misconfigurations. For RBAC, Kubescape provides a comprehensive graph with advanced risk queries to simplify the complexity and prioritize the risk. Advanced filters allow you to group risks by verbs, or do a query about anonymous and who-can exec into pods.

Screenshot of Kubescape CLI Output

The RBAC Visualizer offers a nice and simple navigation, you can group data by verbs, do the layout by type, queries, port forwarding privileged, no impersonation, and misconfiguration about RBAC.

Kubescape is one of the more intuitive open source RBAC security tools, focused on broader Kubernetes posture.

Screenshot of Kubescape RBAC Visualizer

Rbac Police

Rbac-police is an open-source tool developed by the security research team at Palo Alto Networks, a cybersecurity company. This project is based on research around mitigating RBAC privilege escalation in popular applications (e.g. Calico, Cilium) and Kubernetes providers (e.g. AKS, EKS, GKE, OpenShift), as well as research around cross-tenant attacks in Azure Container as a Service ACI through a Privileged Service Account Token. 

This project identifies risky permissions for RBAC using Rego. It contains rules to identify misconfigurations in Kubernetes components  like the kubelet, and shows issues specific to various Kubernetes distributions (EKS, EKS, etc.).

This open source tool has the most in-depth rules base for over permissions, as it is based on security research. 

Screenshot of rbac-police

Detailed Kubernetes Tool Comparison Table for RBAC

The following table compares the tools across the potential risks associated with RBAC settings and events identified in the open source tool's reports, including the risk category (critical, high, warning, low) and a concise description related to RBAC details such as verbs, subjects, and resources. In some cases, additional details can be found within the code rule. Lastly, the table also indicates the open-source tool that covers each specific risk.

These are the main types of RBAC risks:

1. Threats related to managing RBAC according to security best practices and applying minimum permissions: When you create roles to authorize certain Kubernetes resources (deploys, daemonsets, jobs, etc.), it can be very tricky, and mistakes like over permission and misconfigurations are common. Many rules focus on validating the authorizing user (role, role binding, etc.) in Kubernetes resources, e.g. allowing all verbs (*, create, update, etc.) for deployments, jobs, daemonsets, etc.
2. Risks related to a data breach, like who can read secrets, mount volumes, get access to tokens with privileges.
3. Misconfiguration in the Control plane and nodes components such as kubelet, or used outdated cluster versions that will open a window to vulnerabilities and exploitations; or for example, an admin cluster introducing misconfigurations such as an anonymous user with more permissions.
4. Users with access to privileged pods and powerful permissions controls such as exec to the pod, mount, or impersonate users with privileges.
5. Advanced controls to validate advanced kubernetes features such as admissionController or certificateSigningRequest
6. Controls to detect potential risks in kubernetes distributions, for example modify the EKS configmap to gain privileges.
7. Controls to detect vulnerabilities in Kubernetes components, such as CVE-2020-8554 in the load balancer.

By utilizing this table, you can easily identify the associated risks, their severity levels, relevant descriptions, specific code rules, and the corresponding open-source tools that address them.

The role of Kubernetes RBAC in cloud native attacks 

RBAC  plays a significant part in the kill chain for cloud native attacks, including the new, Kubernetes-targeted attacks in 2023:  

• Dero, Monero cryptocurrency miner Kubernetes attacks: In the Dero and Monero cryptocurrency miner Kubernetes attacks in 2023, the attacker’s ability to run a Daemonset and create it’s own malicious pods had an RBAC pre-requisite. In order to gain access, the attacker first scanned for Kubernetes APIs where authentication was set to --anonymous-auth=true (which allows anyone anonymous access to the Kubernetes API), but for this entry point to work, the cluster would also need RBAC configuration that would allow for the creation of pods in that cluster. 
• RBAC-Buster: As its name suggests, this attack from 2023 relied heavily on persistence through the creation of used privileged access in the kube-system namespace to create persistence through a  new ClusterRole that had admin privileges, bound to  a new ServiceAccount to give the ClusterRole’s admin privileges to the ServiceAccount. 
• Software supply chain attacks: For the first time, in 2023, a software supply chain attack was found to be targeting Kubeconfig files. These files hold the authentication data for a cluster, including users, namespaces, and the other information required to communicate with the Kubernetes API. With this, you could see which role bindings are tied to system:masters group, and find any number of ways to get into a cluster.
• Excessive permissions propagated through other tools in the software supply chain: Many of the tools used to manage Kubernetes require high permissions. Since many tools are generally deployed via Daemonsets, which deploy a program across multiple nodes, these permissions can be spread widely throughout an environment. A recent report highlighted the tools that require excessive permissions, and how researchers worked with these tools to reduce the risk of these permissions. For example, EKS and AKS ran a Daemonset to update nodes, which required the ‘update nodes’ permission. But without a way to scope down the permission of the Daemonsets by pod, this meant Kubernetes would permit every node in the Daemon set to run ‘update nodes.’ And with this, a malicious pod could take down every other pod but itself, giving itself undue permissions and control.
• Azurescape: ACI, or Azure Container Instances, is a Container as a Service (CaaS) offering that abstracts away the management of the infrastructure on which containers are deployed. Researchers identified a cross-tenant attack, where an attacker could find its way into somebody else’s containers hosted on ACI. This attack depended on the attackers’ ability to access a privileged Kubernetes Service account token, which they then used to take over the Kubernetes API server and the entire multi-tenant cluster with it. 
• Privilege escalation in FluentBit for GKE: Fluentbit is the default logging tool in GKE, and is installed on each node in the cluster. Researchers found that, if they were able to find a vulnerability in a FluentBit container, they could take advantage of a misconfiguration to read the projected service account tokens and access the token of any pods on the node.  

Without the RBAC components in these attacks, attackers would not have been able to go beyond the initial stages of the attack.

Most frequently observed RBAC security risks

Here are the most frequently observed RBAC security risks highlighted across multiple security reports:

• Misconfigurations in RBAC can result in unauthorized access to resources, such as allowing anonymous requests to the cluster.
• Excessive permissions, this occurs when a user or service account is granted more permissions than necessary to perform its intended activity. Such excessive permissions can lead to unauthorized access to resources and significantly elevate the risk of security breaches.
• Not updating the cluster and using outdated versions leads to vulnerabilities and exploits. Kubernetes releases updated and improved security and patch vulnerabilities, for example, CVE-2020-8559, privilege escalation from compromised node to cluster using Kubernetes v1.18, v1.17 and all kube-apiserver versions prior to v1.16.0.
• Attackers have the potential to exploit authentication paths, seize tokens, infiltrate the cluster, and deploy privileged pods. 
• Reading secrets, in a specific namespace or the whole cluster, important data such as ssh keys, usernames, passwords for applications could be stolen.
• Impersonate privileged accounts
• Unnecessary RBAC roles and bindings pose security risks. The process of assigning roles and permissions is often manual and complex, requiring a deep understanding of the application to apply minimal permissions effectively. Incorrectly defined resources can result in unauthorized access to resources or denial of access. Moreover, unused or unnecessary roles can create security vulnerabilities. Regularly reviewing and removing unused or unnecessary roles is crucial to mitigate the risk of unauthorized resource access.
• The lack of segregation of duties, a fundamental security principle, involves creating separate roles (permissions) for users with distinct responsibilities. This practice is essential to mitigate the risk of security breaches. Without proper segregation of duties, the potential damage can be severe in the event of a security breach.
• Inadequate auditing undermines the ability to monitor RBAC configurations and detect security incidents effectively. Auditing plays a vital role in timely incident detection and reducing the risk of security breaches. Insufficient auditing practices can result in delayed incident detection and heightened security risks.

Any of these security risks can potentially elevate the likelihood of compromising the entire cluster, leading to the exploitation of remote code execution (RCE), lateral movements, and data breaches. The presence of misconfigurations significantly amplifies the higher-risk vulnerabilities. For instance, an attacker granted permission to create pods can leverage this privilege to escalate their access and perform lateral movement within the cluster. This could involve creating a crypto mining container, even within the kube-system namespace.

KSOC secures Kubernetes RBAC with Cloud Native Identity Threat Detection and Response (ITDR) 

Kubernetes RBAC is implicated in many attacks on cloud native environments, and securing RBAC must go farther than posture management. To stop Kubernetes RBAC from being a part of an incident in your organization, you must be equipped with an understanding of the active usage of identities and their relationship to other parts of the kill chain. To truly get a handle on Kubernetes RBAC security, you must:

• Understand and prioritize RBAC, as it is connected to other risks, including CVEs, runtime alerts, other Kubernetes misconfigurations, network issues and Cloud IAM. 
• See the actual activity and usage of identities in your environment, versus a passive view of over permissions (as is in the open source tools detailed above focused on posture management)
• Right-size RBAC issues with an eye toward prioritization, to tackle the largest risks or identities contributing to active incidents first

With KSOC, this is easy and automated across your clusters.

Start with your riskiest identities

In KSOC’s identity inventory, you can see which identities are the riskiest, including which are part of threat vectors. For example, the dashboard below shows you have 30 identities involved in threat vectors. 

KSOC Identity Inventory Dashboard

When you dive into one, in the tv-012 namespace, you will see the risk level. In this case, the risk level is Medium.

Identity inventory

You can see that there are five threat vectors associated with this identity.

Threat vectors associated with an identity

Clicking on the top one gives you the full threat vector, which involves the exposure, via ingress, of cluster-admin. Notice that you can see when activity was last detected for this identity, and when it was first identified.

Threat vector example

Move beyond posture and permissions into actual usage of RBAC permissions

KSOC combines the audit logs for RBAC permissions, telling you how they have been used. In the screenshot below, you can see that not only does the identity have dangerous permissions, it has never been used. It has no misconfigurations, runtime alerts or threat vectors associated with it.  

KSOC Risk factors

When we go to check the last activity (if it has ever been used, which is not the case in the identity above), we see the Kubernetes audit logs indicating what kind of activity occurred and when.

Audit log details for an identity

And for any specific queries about who can do what, you can use AccessIQ to query for usage of any identity or permission. Below, it is answering a query about any allowed attempts to exec into pods with the implicated user, object, namespace and number of times an action occurred.

KSOC AccessIQ

Right-size your RBAC permissions and identities

When you know your riskiest identities and how they are being used, you will need to make decisions around remediation, most likely in partnership with the engineering team. KSOC’s right-sizing recommendations give a before and after view of what needs to change, directly in the manifest code, to fix the issues in any particular identity. 

Right-sizing guidance based on risk

With KSOC, you can finally gain visibility into the Kubernetes RBAC blind spots resulting from the shared service model, and then apply least privilege access with admission control and remediation guidance down to the manifest code.

User management of KSOC itself is also possible with granular permissions across users in your organization, ensuring that different teams have the access required, and no more.

Conclusion

Today, RBAC is the single most vulnerable, and at the same time least addressed, risk factor in Kubernetes. Thankfully, there are many best practices guides available, and a litany of tools to choose from. When making a decision on who can help secure Kubernetes in your environment, be sure to look beyond posture management and into capabilities that reveal actual usage, so you can better prioritize your efforts and get more effective in remediation. To take KSOC’s RBAC capabilities for a test drive in your own environment, get in touch with the team today!

Request a trial of RBAC right-sizing