Une vulnérabilité critique dans Flux2l’outil de livraison continue (CD) pour Kubernetes, peut permettre aux locataires malveillants dans les déploiements multi-locataires de saboter les « voisins » utilisant la même infrastructure hors site.

Flux est une solution de CD ouverte et extensible permettant de synchroniser les clusters Kubernetes avec les sources de configuration. Elle est utilisée par Maersk, Volvo, SAP, Deutsche Telekom et Grafana Labs, entre autres sociétés.

En tant que version 2 de l’outil, Flux2 a introduit la prise en charge de la multi-location, entre autres fonctionnalités.

Mauvaise validation de kubeconfig

Désormais corrigée, la faille d’exécution de code à distance (RCE) résulte d’une mauvaise validation des fichiers kubeconfig, qui « peuvent définir des commandes à exécuter pour générer des jetons d’authentification à la demande », selon un conseil en sécurité publié sur GitHub le mardi 17 mai.

« Flux2 peut réconcilier l’état d’un cluster distant lorsqu’il est fourni avec un fichier kubeconfig avec les droits d’accès corrects. »

Paulo Gomes, ingénieur logiciel senior chez Weaveworks, une société membre de la Cloud Native Computing Foundation (CNCF) qui est à l’origine de GitOps et fournit un support pour Flux et Kubernetes, a expliqué : « Flux peut synchroniser l’état déclaré défini dans un référentiel Git avec le cluster dans lequel il est installé, ce qui est l’approche la plus couramment utilisée. Ou il peut cibler un cluster distant à la place », a-t-il déclaré La gorgée quotidienne.

« L’accès requis pour cibler les clusters distants dépend en grande partie de la portée envisagée. Ceci est complètement flexible et repose sur le RBAC de Kubernetes ayant une large gamme de granularité (d’une seule ressource à l’ensemble du cluster).

Le résultat, selon l’avis, est qu ‘ »un utilisateur malveillant avec un accès en écriture à une source Flux ou un accès direct au cluster cible, pourrait créer un kubeconfig pour exécuter du code arbitraire à l’intérieur du conteneur du contrôleur ».

Disparité CVSS

La vulnérabilité est considérablement moins dangereuse dans les déploiements cloud à locataire unique, ce qui explique qu’elle n’obtienne qu’un score de 6,8 sous l’ancien, CVSS v2 système d’évaluation, ce qui rend le bogue de gravité moyenne.

« La raison en est qu’un attaquant aurait besoin de presque le même nombre de privilèges qu’il obtiendrait en l’exploitant », a déclaré Gomes.

Cependant, la faille est notée 9.9 selon la dernière version CVSS, v3.1car il a introduit une métrique autour des changements de « portée », et – comme First décrit la métrique de portée « modifiée » – la « vulnérabilité peut affecter des ressources au-delà du périmètre de sécurité géré par l’autorité de sécurité du composant vulnérable ».

En effet, les attaquants peuvent également obtenir une élévation des privilèges vers l’administrateur du cluster dans des environnements multi-locataires, à condition que le compte de service du contrôleur dispose d’autorisations élevées.

« Dans le pire des cas, un locataire voyou pourrait perturber la disponibilité, l’intégrité et la confidentialité des autres locataires », a déclaré Gomes. « L’impact dépendrait de la configuration du cluster et des locataires.

« Théoriquement, un locataire non autorisé pourrait déployer des applications dans les clusters d’autres locataires, par exemple. Mais l’impact pourrait être réduit par d’autres contrôles de sécurité en place (c’est-à-dire les contrôleurs d’admission, l’OPA, etc.).

Correctifs et solutions de contournement

Cette vulnérabilité, qui a été découverte par les mainteneurs de Flux, a été corrigée dans Flux2 version v0.29.0, et dans les opérateurs Kubernetes kustomize-controller (corrigé dans la v0.23.0) et contrôleur de barre (v0.19.0).

« A partir des versions fixes, les deux contrôleurs désactivent par défaut l’utilisation de l’exécution de commandes à partir des fichiers kubeconfig, [so] les utilisateurs doivent s’inscrire en ajoutant le drapeau –insecure-kubeconfig-exec aux arguments de commande du contrôleur », explique l’avis.

« Les utilisateurs ne sont plus autorisés à se référer aux fichiers du système de fichiers du contrôleur dans les fichiers kubeconfig fournis pour la fonctionnalité d’application à distance. »

Au lieu d’appliquer des mises à jour, les utilisateurs peuvent se protéger en désactivant la fonctionnalité vulnérable via des webhooks de validation d’admission tels que OPA Gatekeeper ou Kyverno.

Ils peuvent également appliquer des profils AppArmor et SELinux restrictifs sur le pod du contrôleur pour limiter les fichiers binaires pouvant être exécutés.