A critical vulnerability in Flux2, the continuous delivery (CD) tool for Kubernetes, can enable rogue tenants in multi-tenancy deployments to sabotage ‘neighbors’ using the same off-premise infrastructure.
Flux is an open and extensible CD solution for keeping Kubernetes clusters in sync with configuration sources, and is used by Maersk, Volvo, SAP, Deutsche Telekom, and Grafana Labs, among other companies.
As version 2 of the tool, Flux2 introduced multi-tenancy support, among other features.
Improper kubeconfig validation
Now patched, the remote code execution (RCE) flaw arises through improper validation of kubeconfig files, which “can define commands to be executed to generate on-demand authentication tokens”, according to a security advisory posted on GitHub on Tuesday (May 17).
“Flux2 can reconcile the state of a remote cluster when provided with a kubeconfig file with the correct access rights.”
Paulo Gomes, senior software engineer at Weaveworks, a Cloud Native Computing Foundation (CNCF) member company that originated GitOps and provides support for Flux and Kubernetes, elaborated: “Flux can synchronize the declared state defined in a Git repository against the cluster in which it is installed, which is the most commonly used approach. Or it can target a remote cluster instead,” he told The Daily Swig.
“The access required for targeting remote clusters largely depends on the intended scope. This is completely flexible and relies on Kubernetes’ RBAC having a wide range of granularity (from a single resource to the entire cluster).”
The upshot, according to the advisory, is that “a malicious user with write access to a Flux source or direct access to the target cluster, could craft a kubeconfig to execute arbitrary code inside the controller’s container”.
CVSS disparity
The vulnerability is considerably less dangerous in single-tenant cloud deployments, which accounts for it scoring only 6.8 under the older, CVSS v2 rating system, making the bug medium severity.
“The reason being, an attacker would require almost the same amount of privileges it would gain by exploiting it,” said Gomes.
However, the flaw is rated 9.9 according to the latest CVSS version, v3.1, since it introduced a metric around changes of ‘scope’, and – as First describes the ‘changed’ scope metric – the “vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component”.
This is because attackers can also achieve privilege escalation to cluster admin in multi-tenancy environments, provided that the controller’s service account has elevated permissions.
“In the worse-case scenario, a rogue tenant could disrupt the availability, integrity and confidentiality of other tenants,” said Gomes. “The impact would depend on how the cluster and tenants were configured.
“Theoretically, a rogue tenant could deploy applications into other tenants’ clusters for example. But the impact could be reduced by other security controls in place (i.e. admission controllers, OPA, etc).”
Patches and workarounds
This vulnerability, which was discovered by the maintainers of Flux, was fixed in Flux2 version v0.29.0, and in Kubernetes operators kustomize-controller (patched in v0.23.0) and helm-controller (v0.19.0).
“Starting from the fixed versions, both controllers disable the use of command execution from kubeconfig files by default, [so] users have to opt-in by adding the flag –insecure-kubeconfig-exec to the controller’s command arguments,” explains the advisory.
“Users are no longer allowed to refer to files in the controller’s filesystem in the kubeconfig files provided for the remote apply feature.”
In lieu of applying updates, users can protect themselves by disabling the vulnerable functionality via Validating Admission webhooks such as OPA Gatekeeper or Kyverno.
They can also apply restrictive AppArmor and SELinux profiles on the controller’s pod to limit which binaries can be executed.
