Privilege escalation to cluster admin on multi-tenant environments

Vulnerability

In kustomize-controller versions prior to v0.15.0 (included in flux2 prior to v0.18.0), a command injection vulnerability exists when the controller reconciles a Flux Kustomization object that references a Service Account with an associated Kubernetes Secret containing a shell command [1][2]. The controller executes commands embedded in the token field of the Secret, which are run inside the container. This affects multitenant environments where non-admin users can create Service Accounts, Secrets, and Kustomization objects [2].

Exploitation

An attacker who can create Kubernetes Secrets, Service Accounts, and Flux Kustomization objects can exploit this by: (1) creating a Secret with a shell command in the token field, e.g., kubectl create secret generic exploit-token --from-literal="token= || kubectl api-versions", (2) creating a Service Account that references that Secret, and (3) creating a Kustomization that uses that Service Account [2]. When the kustomize-controller reconciles the Kustomization, it executes the embedded shell command as a side effect of processing the Service Account's secrets [1][2].

Impact

Successful exploitation allows an attacker to execute arbitrary shell commands, including kubectl commands, under the Service Account of kustomize-controller. This can lead to privilege escalation to cluster admin rights, as kustomize-controller typically operates with high privileges [1][2]. The attacker gains full control over the cluster, enabling actions such as deploying unauthorized resources, accessing secrets, or modifying system components.

Mitigation

This vulnerability is fixed in kustomize-controller v0.15.0 (included in flux2 v0.18.0), released on 2021-10-08 [1][2]. The fix removes the kubectl binary from the container image and stops executing shell commands on the container OS. For environments that cannot immediately upgrade, administrators can use Kubernetes validating webhooks such as Gatekeeper OPA or Kyverno to prevent creation of Service Accounts with secrets in non-admin namespaces [1][2].