Kubernetes est devenu de loin le système de conteneur cloud le plus populaire. Donc en fait ce n'était qu'une question de temps jusqu'à ce que sa première faille de sécurité majeure soit découverte.
Et c'était le cas, parce que récemment La première faille de sécurité majeure dans Kubernetes a été publiée sous CVE-2018-1002105, également connu sous le nom d'échec de l'élévation des privilèges.
Cette faille majeure dans Kubernetes est un problème car il s'agit d'une faille de sécurité critique CVSS 9.8. En cas de première faille de sécurité majeure de Kubernetes.
Détails de l'erreur
Avec un réseau de demande spécialement conçu, tout utilisateur peut établir une connexion via depuis le serveur d'interface de programmation d'application (API) Kubernetes vers un serveur backend.
Une fois établi, un attaquant peut envoyer des requêtes arbitraires via la connexion réseau directement à ce backend dans lequel à tout moment l'objectif est ce serveur.
Ces demandes sont authentifiées avec les informations d'identification TLS (Transport Layer Security) du serveur d'API Kubernetes.
Pire encore, dans la configuration par défaut, tous les utilisateurs (authentifiés ou non) peuvent exécuter des appels de découverte d'API qui permettent cette élévation de privilèges par l'attaquant.
Ainsi, quiconque connaît ce trou peut en profiter pour prendre le contrôle de son cluster Kubernetes.
Pour le moment, il n'y a pas de moyen facile de détecter si cette vulnérabilité a déjà été utilisée.
Étant donné que les demandes non autorisées sont effectuées via une connexion établie, elles n'apparaissent pas dans les journaux d'audit du serveur de l'API Kubernetes ou dans le journal du serveur.
Les demandes apparaissent dans les journaux de kubelet ou sur le serveur d'API agrégé, mais elles se distinguent des requêtes correctement autorisées et proxy via le serveur d'API Kubernetes.
Abuser de cette nouvelle vulnérabilité dans Kubernetes cela ne laisserait pas de traces évidentes dans les journaux, donc maintenant que le bogue Kubernetes est exposé, ce n'est qu'une question de temps jusqu'à ce qu'il soit utilisé.
En d'autres termes, Red Hat a déclaré:
La faille d'escalade de privilèges permet à tout utilisateur non autorisé d'obtenir des privilèges d'administrateur complets sur n'importe quel nœud de calcul s'exécutant dans un pod Kubernetes.
Il ne s'agit pas seulement d'un vol ou d'une ouverture pour injecter du code malveillant, cela peut également réduire les services d'application et de production au sein du pare-feu d'une organisation.
Tout programme, y compris Kubernetes, est vulnérable. Les distributeurs Kubernetes publient déjà des correctifs.
Red Hat rapporte que tous ses produits et services basés sur Kubernetes, y compris Red Hat OpenShift Container Platform, Red Hat OpenShift Online et Red Hat OpenShift Dedicated sont concernés.
Red Hat a commencé à fournir des correctifs et des mises à jour de service aux utilisateurs concernés.
Pour autant que l'on sache, personne n'a encore utilisé la faille de sécurité pour attaquer. Darren Shepard, architecte en chef et co-fondateur du laboratoire Rancher, a découvert le bogue et l'a signalé à l'aide du processus de rapport de vulnérabilité de Kubernetes.
Comment corriger ce défaut?
Heureusement, un correctif pour ce bogue a déjà été publié. Dans lequel seulement ils sont invités à effectuer une mise à jour de Kubernetes afin qu'ils puissent choisir certaines des versions corrigées de Kubernetes v1.10.11, v1.11.5, v1.12.3 et v1.13.0-RC.1.
Donc, si vous utilisez toujours l'une des versions de Kubernetes v1.0.x-1.9.x, il est recommandé de passer à une version fixe.
Si, pour une raison quelconque, ils ne peuvent pas mettre à jour Kubernetes et ils veulent arrêter cet échec, il est nécessaire qu'ils effectuent le processus suivant.
Vous devez arrêter d'utiliser l'API des agrégats de serveur ou supprimer les autorisations d'exécution / d'attachement / de transfert de port pour les utilisateurs qui ne devraient pas avoir un accès complet à l'API kubelet.
Jordan Liggitt, l'ingénieur logiciel de Google qui a corrigé le bogue, a déclaré que ces mesures seraient probablement préjudiciables.
La seule vraie solution contre cette faille de sécurité est donc d'effectuer la mise à jour Kubernetes correspondante.