Database/Container, Kubernetes & orchestration
Apache CloudStack CKS: cross-tenant manipulation of Kubernetes clusters when adding or removing nodes
Impact
An account on a shared CloudStack deployment can act on Kubernetes clusters that belong to another tenant during node add and node remove operations, because the CKS plugin does not properly enforce ownership on those calls. On a multi-tenant GPU cloud where CKS provisions the tenant Kubernetes clusters that schedule GPU instances, that is a direct tenancy break: a neighbour can attach nodes to, or strip nodes from, someone else's cluster. Attaching a node the attacker controls to a victim cluster puts attacker-controlled kubelets inside the victim's cluster trust boundary; removing nodes is a straightforward denial of service against a running training or inference fleet. The advisory does not describe exploitation in the wild.
Who can reach it
Any authenticated CloudStack user account on the deployment that can reach the CKS API - no administrator role stated. Not exploitable from outside the management API.
What to do
Upgrade CloudStack to 4.22.1.1 or later; 4.21.0.0 through 4.22.1.0 are affected. This is a management-server upgrade and restart, not a change on the hypervisor or GPU nodes, so running tenant workloads do not need to be drained. Until the upgrade lands, audit CKS cluster membership for nodes nobody recognises.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.