🐶 😆 ⚗️ Aller au-delà du pod dans Kubernetes grâce aux journaux de montage 👨🏼‍⚕️ ⚛️ 🎅🏾

Remarque perev. : Cette note a été rédigée par un chercheur en sécurité informatique chez Aqua Security, une société DevSecOps. Elle est une excellente illustration des subtilités de la configuration de Kubernetes, qu'il est important de toujours garder à l'esprit lorsque vous servez des clusters en production. Bien sûr, si vous pensez à leur sécurité ...

Kubernetes se compose de nombreux composants, et parfois leur combinaison d'une certaine manière conduit à des résultats inattendus. Dans cet article, je montrerai comment un pod lancé avec des privilèges root et un répertoire /var/log monté d'un nœud peut étendre le contenu de l'ensemble du système de fichiers hôte à un utilisateur ayant accès à ses journaux. Nous discuterons également des solutions à ce problème.

Comment Kubernetes voit les journaux

Vous êtes-vous déjà demandé comment kubectl logs <pod_name> extrait les journaux du pod? Qui est responsable de la collecte des grumes dans les conteneurs? Et comment arrivent-ils sur votre ordinateur?

Le diagramme suivant illustre le processus:

Kubelet crée une structure à l'intérieur du répertoire /var/log sur l'hôte qui représente les pods sur l'hôte. Il y a un fichier 0.log (1) dans le répertoire de notre 0.log , mais en fait c'est un lien symbolique vers le journal du conteneur situé dans /var/lib/docker/containers . Tout cela du point de vue de l'hôte.

Kubelet ouvre le noeud final /logs/ (2), qui fonctionne simplement avec le serveur de fichiers HTTP dans le répertoire (3), rendant les journaux disponibles pour les demandes provenant du serveur API.

Imaginez maintenant que nous avons déployé pod avec hostPath monté dans /var/log . Un tel pod aura accès à tous les fichiers journaux de l'hôte. Bien que cela soit en soi un problème potentiel, nous pouvons franchir la prochaine étape logique. Et si nous remplaçons 0.log par un lien symbolique pour ... par exemple, /etc/shadow ?

 │ ├── var │ ├── logs │ │ ├── pods │ │ │ ├── default_mypod_e7869b14-abca-11e8-9888-42010a8e020e │ │ │ │ ├── mypod │ │ │ │ │ ├── 0.log -> /etc/shadow │ │ │ │ │ │

Maintenant, en essayant de télécharger les journaux à l'aide des journaux kubectl logs sur la machine cliente, nous obtenons:

 $ kubectl logs mypod failed to get parse function: unsupported log format: "root:*:18033:0:99999:7:::\n"

Kubelet suit le lien et lit le contenu du fichier vers lequel il pointe (il peut s'agir de n'importe quel fichier sur le nœud).

Comme JSON était attendu, kubectl s'est écrasé après la première ligne, cependant, nous pouvons facilement lire les lignes spécifiques du fichier shadow en exécutant la commande avec l' –-tail=-<line_number> .

C'est incroyable. Puisque kubelet suit le lien symbolique, vous pouvez utiliser ses privilèges root pour lire n'importe quel fichier sur le nœud, simplement en créant un lien symbolique à l'intérieur du pod.

Échapper au pod

Allons encore plus loin. Nous savons que lors du démarrage d'un pod dans Kubernetes, le jeton ServiceAccount y est installé. Ainsi, si le compte de service permet d'accéder aux journaux, nous pouvons accéder directement aux privilèges kubelet et root sur le nœud.

J'ai écrit une preuve de concept (POC) démontrant ce vecteur d'attaque:

déploiement de pod avec point de montage /var/log ;
créer un lien symbolique vers le répertoire racine de l'hôte;
lecture de la clé privée ssh de l'utilisateur sur l'hôte.

La vidéo suivante montre deux commandes spéciales qui s'exécutent à l'intérieur d'un pod:

lsh == ls (sur le système de fichiers hôte);
cath == cat (sur le système de fichiers hôte).

Remarque perev. : Malheureusement, ils n'ont pas corrigé l'insertion de contenu d'asciinema sur le hub, bien que nous ayons déjà résolu ce problème, nous sommes donc obligés «d'intégrer» la vidéo avec le lien simple ci-dessus.

Tous les fichiers impliqués dans ce POC peuvent être trouvés dans le référentiel GitHub correspondant . Il existe un autre script POC qui collecte automatiquement les clés privées et les jetons ServiceAccount du système de fichiers hôte.

Le montage de répertoires peut être dangereux

Est-ce donc une vulnérabilité ou une mauvaise pratique?

Le déploiement d'un pod avec un hostPath ouvert en écriture dans /var/log est rare (en outre, il existe d'autres façons d'abuser du montage de répertoires secrets d'hôte dans le pod). Mais même si vous saviez que le montage /var/log était une pratique douteuse, vous ne vous attendiez probablement pas à ce qu'il vous permette de reprendre le nœud avec une telle facilité.

Avant la publication, nous avons contacté l'équipe de sécurité de Kubernetes pour savoir si elle considérait cela comme une vulnérabilité. Ils ont conclu que ce n'était qu'une triste conséquence de la création d'un répertoire hôte privé avec des autorisations d'écriture: les risques impliqués sont bien documentés . Cependant, cette vulnérabilité est assez facile à exploiter. Dans le monde, de nombreux projets utilisent cette monture. Si vous utilisez l'un de ces projets, n'oubliez pas que votre déploiement sera vulnérable à cette façon de détourner l'hôte.

Cette méthode a été testée sur Kubernetes 1.15 et 1.13, mais affecte très probablement d'autres versions.

Élimination

Une telle «fuite» n'est possible que si le pod s'exécute en tant que root. Cela devrait généralement être évité . Aqua CSP vous permet de définir une politique avec un minimum d'efforts qui empêche les conteneurs de s'exécuter sous la racine ou accorde des autorisations uniquement à un groupe spécifique d'images qui ont vraiment besoin de la racine.

Une autre façon consiste simplement à ne pas déployer de pods avec hostPath avec des autorisations d'écriture dans /var/log . Cette approche n'est pas définie par défaut et n'est pas une pratique courante, il est donc nécessaire de la déterminer consciemment (cependant, la possibilité demeure). Mais comment vérifier?

Nous avons ajouté un nouveau script (hunter) à kube-hunter - notre outil Open Source léger pour tester Kubernetes - qui vérifie le cluster pour les pods avec de tels points de montage dangereux. ( Remarque : Kube-hunter était présent dans une récente revue des utilitaires de sécurité K8, que nous avons publiée sur notre blog.)

Les utilisateurs d'Aqua peuvent se protéger de ce risque en utilisant la stratégie d'exécution pour empêcher le montage de certains volumes:

Remarque perev. : Une partie de ce problème peut être résolue à l'aide des stratégies de sécurité des AllowedHostPaths , à savoir AllowedHostPaths . Cependant, ce n'est pas non plus une protection contre les liens symboliques. Enfin, comme le suggèrent les commentaires, nous pouvons simplement limiter le lancement en tant que root, là encore guidé par la PSP .

Résumé

Kubernetes est un système complexe avec beaucoup de subtilités dans les paramètres de sécurité, qui ne sont pas toujours évidents pour l'utilisateur moyen et même expérimenté. Dans cet article, j'ai montré comment, dans certaines circonstances, une journalisation innocente peut entraîner une vulnérabilité potentielle. Dans la plupart des cas, cela n'est pas possible, mais Kubernetes offre aux utilisateurs une plus grande liberté d'action qui peut affecter la sécurité. Il est important de garder cela à l'esprit et de mettre en œuvre des contrôles appropriés pour éviter de telles erreurs.

PS du traducteur

Lisez aussi dans notre blog: