Identity Threat Detection and Response (ITDR) has become indispensable to security teams, especially as identity’s critical role in multiple security breaches continues to make headlines. But today in many organizations, ITDR has a major gap when it comes to cloud native and Kubernetes RBAC.
Three of the four major attacks targeting Kubernetes in 2023 relied on overly permissive RBAC identities. In 2024, for the first time, software supply chain attacks targeted kubeconfig files, and a recent survey showed that 58% of teams using Kubernetes had a security issue in the last 12 months with insufficient access controls in their Kubernetes environment.
In this blog, we will discuss what is required to apply ITDR to cloud native security, with Kubernetes RBAC.
Contents:
What is Identity Threat Detection and Response (ITDR)?
What Are the Unique Challenges of ITDR with Kubernetes RBAC?
Posture Management with CIEM and KIEM tools: the legacy approach to securing Kubernetes RBAC
ITDR Best Practices Checklist for Kubernetes RBAC
Use ITDR to meet compliance requirements for Kubernetes RBAC, including SOX, SOC2 and FedRAMP
User Access Reviews for Kubernetes RBAC
Use RAD Security's Cloud Native ITDR to stop malicious insiders
RAD Security Cloud Native ITDR Cost Savings
ITDR tools detects incidents in your identities and provide a way to right-size, delete, block, or otherwise respond in the case that an identity is identified as malicious. The detection of a malicious identity can take many forms, and depends very much on the area of focus. In the case of IAM, the focus would be on malicious logins, perhaps from suspicious locations, or multiple locations all at the same time. In the case of service accounts or machines, one might focus on which user has created the service account, how long it has been in use, or unused. And responses can vary from blocking certain users from logging in, to right-sizing a service account down to least privilege access by removing the verbs get, list and watch if those permissions have gone unused. ITDR capabilities and requirements vary greatly based on the area of focus.
In a zero trust program, ITDR would be the ultimate check against anything that might have gotten through the guardrails and least privilege access policies put in place. ITDR tools would also, ideally, provide strong recommendations, based on malicious activity, to improving identity posture.
Gartner recently labeled ITDR as one of the top security and risk management trends, naming focus areas like Identity and Access Management (IAM) tooling and insider attacks. And all signs point to the prioritization of ITDR as a part of zero trust initiatives in 2024; recent research places identity and access management and cloud infrastructure as the top two areas of focus for CISOs in 2024. Another recent survey showed that identity has moved up to be the second top priority for CISOs, followed closely by cloud infrastructure security, compared to the 8th top priority last year. And analysts forecast an uptick of 10% in the number of organizations that will have a measurable zero trust program in place over the next year. Identity Threat Detection and Response (ITDR) is like having a security guard for your digital identity. Just like how a security guard watches over a building and checks for anyone suspicious, ITDR keeps an eye on your digital information—like your usernames and passwords—to make sure no one's trying to steal or misuse them.
The advent of cloud and cloud-native technologies, including containers and Kubernetes, has exponentially increased the number of identities, expanding the scope of security teams' detection and response efforts. Kubernetes RBAC (Role-Based Access Control), in particular, presents a unique challenge due to its complexity and the absence of clear ownership between developers and security teams.
Challenges of ITDR with RBAC include:
ITDR is important because, in the case of a cloud native attack, it is the only solution that could discover or mitigate the large role played by RBAC in cloud native attacks.
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 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.
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.
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.
Before vendors and researchers had found and publicized their fixes and mitigations for these issues, the only thing that could have helped identity an attacker taking advantage of these issues would have been an ITDR solution for Kubernetes RBAC. And in this context, an ITDR solution would need to understand the usage of valid permissions, prioritize risks based on a holistic view of the threat landscape, including runtime events, and in the best case scenario, be able to right-size identities.
Historically, RBAC security tools were designed to enhance identity posture and implement hardening strategies. While Cloud Identity and Entitlements Management (CIEM) focuses on Cloud IAM, Kubernetes Identity and Entitlements Management (KIEM) is solely focused on posture for Kubernetes RBAC, with the following capabilities:
But posture is not actual behavior, nor is it a checklist for RBAC security. With ITDR, you can expect more than just laundry lists of permissions, including understanding actual usage of valid permissions, how to right-size, which identities are unused, and which identities are top priority based on their relationship to other contextual factors like runtime events, image CVEs and more.
Difference between Cloud Native ITDR vs KIEM tools
If you truly want to be able to detect and respond to any compromises of the Kubernetes RBAC identities across your environment, you will need to ensure any tool you use can match the following ITDR best practices checklist for Kubernetes RBAC, and not just Cloud IAM.
Kubernetes RBAC ITDR Checklist
Download the Cloud Native ITDR Best Practices Checklist
RAD Security recently launched cloud native ITDR, introducing attack paths across Cloud IAM and RBAC, as well as AccessIQ, an AI-based query engine to investigate the actual usage of RBAC permissions.
RAD Security's ITDR solution stops Kubernetes RBAC from being part of an incident in your organization, going farther than posture management with an understanding of the active usage of identities and their relationship to other parts of the kill chain. With RAD Security, you can truly get a handle on Kubernetes RBAC security by:
With RAD Security, this is easy and automated across your clusters.
Check out RAD Security's Cloud Native ITDR capabilities
RAD Security's ITDR solution addresses Kubernetes RBAC in the following ways:
RAD Security identity inventory with risk ratings
RAD Security risk analysis screenshot for service account
Example of Admission Control Response Policy for RBAC
RAD Security usage risk analysis
Here are also the audit logs, showing the actual activity details for that service account.
RAD Security RBAC identity audit log view
Filter by type
Filter by source
Service account roles and permissions in RAD Security
RAD Security right-sizing example
Customers and regulators today require that requirements are met for Kubernetes environments. ITDR should provide the necessary detection and response capabilities, along with the least privilege guidelines, to meet these requirements.
User access reviews involve periodically examining and validating a user’s access rights to ensure an organization is appropriately assigning and adjusting them as the organization changes, all following the principle of least privilege. The end result is a printed report that shows the access review from that quarter, as well as a list of follow-ups for any issues found in the review. Some of the most difficult issues in these reviews, and the areas with the biggest penalties, involve improper offboarding of former employees, as well as unused identities.
RAD Security helps to automate this process for Kubernetes RBAC, and is particularly helpful in the area of unused identities, leveraging insight into how identities are or are not being used. User access reviews are a critical part of SOX, SOC2, PCI, and FedRAMP compliance.
Until now, for teams to be able to do this in Kubernetes, even with any of the KIEM or open source RBAC tools available, it would be a manual, lengthy process.
With RAD Security, finding malicious insiders is simple and automated.
Starting on the identity inventory page will tell you which are your riskiest identities, taking into account actual incidents, usage of the identity, and connections to workloads with other kinds of risks that are being exploited.
RAD Security identity inventory, filtered by risk level
From there, filtering for those identities that include active runtime alerts and are part of a threat vector will tell you where workloads associated with identities are actively being exploited.
RAD Security threat vector and runtime alert filter
Any of those identities that are part of an active incident can then be investigated and right-sized, to shut down any of the exploited permissions that caused the incident in the first place.
RAD Security Identity Relationships Map
RAD Security zero trust policy generator
RAD Security's Cloud Native ITDR solution is able to assess identity in the context of multiple other components in the environment, with a much broader understanding of holistic risk than traditional Cloud/Kubernetes Identity and Entitlements Management (CIEM/KIEM) solutions.
Just bringing in audit logs, and making them queryable, can take a much longer time than a RAD Security installation. For example, for EKS, ingesting audit logs requires a lambda trigger from Cloudwatch or Kinesis to route the logs to save to an S3 bucket or another destination for further processing. Then, a query engine would have to format the logs properly before they can even be queried. Along the way, there might also be a big price tag from a SIEM provider.
Cost and time savings with RAD Security Cloud Native ITDR
ITDR is a critical capability in any zero trust strategy, and is also a critical piece of a detection and response strategy, given the consistency of identity in any attack kill chain. This is no different when it comes to identity in Kubernetes, and RBAC security, where software supply chain attacks and other Kubernetes tools can easily spread elevated privileges across an entire multi-cluster environment. It is much more effective, in terms of prioritization and remediation, to work with a solution focused on the actual, malicious usage of valid credentials, and not just laundry lists of over permissions.
Reach out to the RAD Security team today to automatically generate zero trust policy recommendations in your environment, as a first step toward adding ITDR to your overall zero trust and incident management strategies.
Request a trial of Cloud Native ITDR