Intro
A new vulnerability in Kubernetes was recently announced, bringing the total number of Kubernetes vulnerabilities to forty-nine. Notably, this vulnerability in the Kubernetes CSI Driver is the first Medium rated vulnerability since 2021. A recent analysis, using the Exploit Prediction Scoring System (EPSS), demonstrated that the CVSS severity level was not entirely indicative of the probability of a CVE being exploited in the wild, so it’s important to take every Kubernetes CVE seriously. In this blog we will detail how to either fix the issue or ensure this Kubernetes vulnerability doesn’t affect your environments.
What is the Kubernetes CSI driver
The Kubernetes Container Storage Interface (CSI) was introduced as an alpha capability to Kubernetes in v1.14. The main idea of the CSI, at its inception, was to create an alternative to plugins that were made to live inside the Kubernetes codebase, specific to each kind of storage vendor. Creating the CSI eliminated the need for these plugins, to enable better central maintainability and control while lowering the attack surface.
Storage vendors create CSI drivers that integrate with the Kubernetes CSI, keeping the custom code for each vendor outside of Kubernetes, while still allowing Kubernetes to work with the storage vendors. Virtually any Kubernetes environment that has an integration with a storage driver will use some kind of a CSI driver, including managed cloud platforms. As most storage vendors for Kubernetes are cloud services, this is a particularly relevant vulnerability for anybody running their Kubernetes clusters in a cloud service.
How does the vulnerability work?
The Kubernetes CSI provides something called a secrets-store-CSI-driver, which is a daemon-set on each kubelet (by definition one on each node). It runs as root in privileged mode because one of its jobs is to retrieve the secrets content from an external secrets store, which is done by mounting new tmpfs filesystems to existing pod filesystems.
In CVE-2023-2878, when TokenRequests is configured and the driver is set to run at log level 2 or greater via the -v flag, the driver will disclose service account tokens in logs. Since logs are generally shipped multiple places for observability, security, compliance or audit purposes, in a normal Kubernetes environment, this could create very broad exposure. With this vulnerability, anybody with access to the log would have a service account token that could be used in that cluster to access secrets from cloud vault providers.
What you should do
There are a few ways to mitigate this issue. First, you can run the secrets-store-csi-driver at log level 0 or 1 via the -v flag. Alternatively, you can upgrade the secrets-store-csi-driver to version 1.3.3, which is compatible with any version of Kubernetes that is at least v1.19, or more recent. You can follow the information from the official guidance to see if tokens are configured in the first place.
How Rad Security can help
Rad Security can scan your running images to find this vulnerability in the secrets-store-csi-driver (which, again, is deployed via a daemonset, or a group of containers and hence has associated images which can be scanned).
Conclusion
This year has been a big one in terms of Kubernetes CVEs, especially when you group in the vulnerabilities found with external third-party tooling. If you are running KSOC in your environment, you can easily find and fix vulnerabilities like this. Contact us today for a demo to see real-time security for your clusters in action.
