Skip to content
bg blog
Jeff FriedmanApr 13, 2023 9:00:00 AM4 min read

CVE-2023-30512 & CVE-2023-30513 Kubernetes Vulnerabilities

Let’s face it, the vast majority of software running inside of a Kubernetes cluster comes from sources that are out of your control. Kubernetes makes it incredibly easy for developers to install everything they need to spin up build systems, install proxies, roll out databases, and more in a single command. This is undeniably one of the compelling uses of the Kubernetes platform, but what does it mean for risk and how are we tracking this in the supply chain?

Just this week alone, two CVEs were released that impact popular third-party software distributions in Kubernetes. Each of these CVEs represents a unique threat, but hints at a bigger problem in Kubernetes; how we as practitioners actually detect and ultimately remediate CVEs from outside sources. Let’s dive in further.

Two New Kubernetes Vulnerabilities

CVE-2023-30512 at the time of this writing does not have a risk score but that doesn’t mean that we can’t infer some key risks. CubeFS is a CNCF project that acts as a cloud native distributed platform. In Kubernetes, CubeFS is used for data processing services and machine learning jobs. The installation in the cluster is done using a DaemonSet which in essence tells the Kubernetes API to run the pod(s) on each node in the cluster. The CVE states that the DaemonSet relies on a cluster-role called cfs-csi-cluster-role which has the following RBAC configuration:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cfs-csi-cluster-role
rules:
  - apiGroups: [ "" ]
    resources: [ "nodes","pods" ]
    verbs: [ "get", "list", "watch" ]
  - apiGroups: [ "" ]
    resources: [ "secrets" ]
    verbs: [ "get", "list" ]
  - apiGroups: [ "" ]
    resources: [ "events" ]
    verbs: [ "list", "watch", "create", "update", "patch" ]
  - apiGroups: [ "" ]
    resources: [ "persistentvolumes" ]
    verbs: [ "get", "list", "watch", "create", "update", "delete", "patch" ]
  - apiGroups: [ "" ]
    resources: [ "persistentvolumeclaims" ]
    verbs: [ "get", "list", "watch", "update", "patch" ]
  - apiGroups: [ "" ]
    resources: [ "persistentvolumeclaims/status" ]
    verbs: [ "patch" ]
  - apiGroups: [ "storage.k8s.io" ]
    resources: [ "storageclasses" ]
    verbs: [ "get", "list", "watch" ]
  - apiGroups: [ "storage.k8s.io" ]
    resources: [ "csinodes" ]
    verbs: [ "get", "list", "watch" ]
  - apiGroups: [ "storage.k8s.io" ]
    resources: [ "volumeattachments" ]
    verbs: [ "get", "list", "watch", "create", "update", "delete", "patch" ]
  - apiGroups: [ "storage.k8s.io" ]
    resources: [ "volumeattachments/status" ]
    verbs: [ "patch" ]

Because this is a ClusterRole these permissions are scoped to the entire cluster. The issue in question per this CVE is the ability to get and list secrets cluster-wide. This means that the DaemonSet used by CubeFS can essentially read all secrets throughout the cluster including administrative ones in the kube-system namespace. The OWASP Top Ten for Kubernetes actually outlines this exact risk clearly when it comes to using the get and list verbs for secret retrieval. This is a classic example of a subtle yet dangerous overly permissive third-party RBAC configuration.

To combat this, the CubeFS DaemonSet should evaluate the need to be retrieving secrets at this level and scope down the permission to only the namespaces or secret objects required within this RBAC configuration. We have written and spoken about RBAC misconfigurations here at KSOC if you’d like to learn more check out the following links:

Jenkins Kubernetes Plugin Vulnerability

CVE-2023-30513 affects the Jenkins Kubernetes Plugin. Jenkins itself is a powerful system that has had its share of vulnerabilities over the years. This plugin instantiates agents in a Kubernetes cluster to give CI jobs the ability to scale up and down dynamically. Jenkins typically does a good job of masking strings that it deems sensitive such as passwords or connection strings when they are passed to the build log but in the case of the Kubernetes plugin, they are not properly masked.

The impact here can vary but any time that you see credentials flying across the wire into logs it should raise alarm bells. The Jenkins build logs may be collected centrally within the cluster by other third-party monitoring systems, shipped to SIEM tools, or just captured directly using kubectl. The shared responsibility within Kubernetes makes this particular CVE a dangerous one as the security team may actually not know where the un-masked values end up or what is the resulting blast radius.

The Solution? Get a real-time Kubernetes gap assessment

So how do we react quickly to vulnerabilities like these and ensure our clusters are adequately protected? KSOC provides a real-time gap assessment, up to the last engineering change, and a view of identity and entitlement that finally sheds light on the web of Kubernetes RBAC permissions. We combine this context for an accurate view of highest priority risk, and use transparent admission control policies to actively reduce your potential blast radius. Schedule a demo to learn more!

RELATED ARTICLES