Less than one month after three high severity Kubernetes vulnerabilities were published for ingress controllers for nginx, the second high severity CVE relevant for Windows endpoints in 2023 has now been published. Though the severity rating is high, it is relatively unlikely that this vulnerability is relevant in your environment given the double requirement of Windows nodes (much less common than Linux) and in-tree storage plugins (deprecated in favor of CSI since Kubernetes v1.14 in 2019, 4 years ago).
There are three main pieces of Kubernetes involved in this CVE: Windows nodes, in-tree storage plugins and persistent volumes. Let’s examine each to understand their interplay and the chance of any of them being present in your environment.
In general, Windows has lagged behind Linux in support for Kubernetes. It was only in 2019, after three years of work, in v1.14, when production level support for Windows nodes was added to Kubernetes. Running Kubernetes on Windows nodes is still not exactly the same as running Kubernetes on Linux nodes. For example, for object permissions, Windows uses SIDs, ACLs and usernames, compared to Linux’s userIDs and groupIDs.
For the reasons above, along with others, Windows nodes are, in general, not as commonly used as Linux nodes. Though there are large services today using Windows nodes, Windows is rarely used on its own. For example, one of the biggest users of Windows in Kubernetes is the group of Microsoft services powering Office 365 and Microsoft 365, which run on Azure Kubernetes Service (AKS). But AKS itself, for other services, runs on a mix of Linux and Windows nodes.
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.
Today, new in-tree volume plugins are not allowed in Kubernetes, for many reasons, including:
- They create plugin code dependencies and impossible maintenance requirements tied to Kubernetes releases
- In-tree plugin bugs can crash critical Kubernetes components
- In-tree plugins allow volume plugins privileges equal to other kubernetes components (like kubelet and kube-controller-manager)
- In-tree plugin code would need to be public
A PersistentVolume is a resource for a cluster, and can be pointed to via an in-tree storage plugin, as is the case with these in-tree PersistentVolume types:
awsElasticBlockStore - AWS Elastic Block Store (EBS) (not available in v1.27)
azureDisk - Azure Disk (not available in v1.27)
cinder - Cinder (OpenStack block storage) (not available in v1.26)
photonPersistentDisk - Photon controller persistent disk. (not available starting v1.15)
scaleIO - ScaleIO volume. (not available starting v1.21)
flocker - Flocker storage. (not available starting v1.25)
quobyte - Quobyte volume. (not available starting v1.25)
storageos - StorageOS volume. (not available starting v1.25)
In CVE-2023-5528, the data suggests that there is a scenario with in-tree storage plugins for Windows nodes where insufficient input sanitization can allow a user admin privileges on the cluster nodes if that user can already create pods and PersistentVolumes.
It is not clear exactly how this works, but it is reasonable to assume a scenario where the privileges granted to somebody who can create pods and PersistentVolumes might accidentally become excessive. The Kubernetes SIG-storage team stated one of the reasons in-tree plugins were deprecated was the fact that, “In-tree volume plugins grant volume plugins the same privileges as kubernetes components (like kubelet and kube-controller-manager).”
Even though this CVE is rated as high severity, it is not as likely that your environment will be affected, compared to the last Kubernetes CVE on Windows nodes, which also pertained to storage.
That being said, here are examples of in-tree plugins that would be relevant in this CVE:
You will need to definitively find out if you are using Windows nodes, using this command:
`kubectl get nodes -l kubernetes.io/os=windows`
In the case that you are running Windows nodes and have in-tree plugins, since the in-tree plugins run on the kubelet, the recommended guidance is to update the Kubelet to:
- kubelet v1.28.4
- kubelet v1.27.8
- kubelet v1.26.11
- kubelet v1.25.16
It is hard enough to keep on top of all the new CVEs in Kubernetes and the third party Kubernetes ecosystem, let alone getting central visibility into how you may be affected or where the vulnerability might be exploited.
To prevent exposure, you need to:
This vulnerability, while rated high in severity, is less likely to be present in your environment because of the dual requirements of in-tree plugins for storage as well as Windows nodes, which are much less common than Linux. Even so, this is the second high severity vulnerability in Kubernetes within the last month, so it’s important to sort out any potential impact of these CVEs on your or your business partners’ environments.