Skip to content
bg blog-1
Jeff FriedmanApr 26, 2023 2:34:40 PM3 min read

CVE-2023-30622: Clusternet Kubernetes Vulnerability


This week, a new vulnerability, CVE 2023-30622, was published for Clusternet, an open source project that helps users manage Kubernetes clusters at scale. This CVE represents both a significant issue for Clusternet users as well as a significant addition to the recent increase of CVEs in third party Kubernetes tooling. 

What is Clusternet?

Clusternet is an open source CNCF project that helps users manage large numbers of Kubernetes clusters. The project currently has 1.1 thousand stars on Github; for comparison, popular open source vulnerability scanner Trivy has 17.1  thousand stars and the relatively new open source runtime tool Tetragon has 2.3 thousand stars. That being said, Clusternet is meant to be used primarily for Kubernetes environments with thousands, or even millions, of clusters, so the impact for any one team using the tool is potentially very large. Clusternet is managed through a SaaS console, helping to “deploy and coordinate applications to multiple clusters from a single set of APIs in a hosting cluster,” which further exacerbates the impact of any vulnerability in the tool.

How does the vulnerability work?

To use Clusternet, you use a deployment called cluster-hub which runs on random worker nodes. In this vulnerability, the deployment runs a misconfigured RBAC policy by running a service account cluster role which by default has a wildcard verb of "*". What this means is that, if an attacker can access the node the cluster-hub deployment is running on, it could leverage that service account and then use any verbs. This could include verbs like get, list and watch which an attacker could then use to obtain the secrets for the entire cluster and escalate privileges.  The attack complexity is high, so this CVE has been rated as Medium.

What should I do?

If you are not running Clusternet, you don’t need to do anything, you are not vulnerable. If you are running Clusternet, you should update to v0.15.2 or later to get the fix. Be sure to check the official Github documentation and the CVE listing for updates. 

Another CVE in Kubernetes third party tooling

Though Clusternet is not the most widely used tool for Kubernetes, as mentioned above, it is meant to be used primarily for Kubernetes environments with thousands, or even millions, of clusters. So for anybody using Clusternet, this vulnerability represents a significant security issue requiring immediate attention. 

For the rest of the ecosystem not using Clusternet, this CVE combined with the others we have seen just in the last few months in Kubernetes third party tooling, should point to the broad ecosystem surrounding Kubernetes that is as vulnerable to supply chain attacks as the rest of the application development lifecycle. 

Just two weeks ago, three different CVEs were announced, affecting plugins for Kubernetes like CubeFS and Jenkins. Before that, we saw a CVE in Crossplane that was rated as High.

How KSOC Can Help

This specific vulnerability is caused by an RBAC misconfiguration, allowing for a role with a wildcard value. KSOC would be able to identify this over-permission in your cluster for any user or service account. In the case that it was too late and an attacker had succeeded in escalating privileges, we would be able to see the action in real-time and any other misconfigurations they had exploited, plus you can set admission control policies to prevent further escalation or movement. It takes seconds to compromise a vulnerability, so real-time Kubernetes Security Posture Management is critical to protect against any new vulnerabilities. 

Request a demo today to see what real-time Kubernetes Security Posture Management looks like, or read more here


Jeff Friedman

Jeff Friedman is a staff software engineer at RAD Security. He has built cloud-native, high-performance distributed systems in product engineering teams at CircleCI and EverQuote, ranging from real time data analysis and data visualization applications to auction engines for insurance marketplaces. Prior to software engineering, Jeff worked in investment banking and management consulting.