Écrit par : Yu Pengfei , Mah Chia Hui

Introduction

La croissance explosive de l'utilisation de Kubernetes au cours de la dernière décennie a été un immense spectacle. Cependant, Rome ne s'est pas construite en un jour et, comme toutes les autres grandes piles technologiques utilisées aujourd'hui, il a fallu plusieurs décennies pour que la technologie de conteneurisation mûrisse avant que Kubernetes ne se présente comme la meilleure articulation à son stade actuel.

À mesure que de plus en plus d'applications sont conteneurisées, les moteurs d'orchestration tels que Kubernetes sont devenus extrêmement populaires. En tant que moteur d'orchestration, Kubernetes aide à gérer, mettre à l'échelle et déployer des applications conteneurisées. Cela dit, il existe des tonnes de moteurs d'orchestration différents (tels que Docker Swarm) - alors pourquoi Kubernetes reste-t-il si populaire ? Une réponse rapide réside dans le fait que Kubernetes est riche en fonctionnalités, doté de capacités telles que l'auto-réparation et la mise à l'échelle automatique. De plus, Kubernetes est implémenté en tant que service géré par la plupart des fournisseurs de services cloud (CSP). Cela consolide sa position de "Gold standard" pour les moteurs d'orchestration. L'adoption de Kubernetes continue de croître, 96 % des organisations utilisant ou évaluant Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Mo' Chérie Mo' Problèmes

Avec l'utilisation généralisée de Kubernetes, il n'est pas surprenant qu'il s'agisse également d'une surface d'attaque prisée que les attaquants tentent activement de détecter et d'exploiter. Avec son ascension nouvelle, les développeurs font également des erreurs dans sa mise en œuvre, sa configuration ou son déploiement.

Cet article est le premier de notre série concernant la sécurité Kubernetes. Il fournira un aperçu de certaines attaques courantes et des meilleures pratiques de sécurité de base pour Kubernetes. Les articles suivants approfondiront les attaques plus complexes, telles que le montage HostPath, les pods/nœuds de trampoline, etc., et leurs corrections.

Pour comprendre les attaques, il faut d'abord comprendre l'architecture Kubernetes, le schéma de haut niveau ci-dessous est un bon point de départ. N'hésitez pas à passer à "Méthodologie d'attaque" si vous connaissez déjà l'architecture Kubernetes et ses principes fondamentaux.

Schéma d'architecture Kubernetes

Gousses

Kubernetes comprend de nombreuses pièces mobiles, et son unité de travail la plus basse est connue sous le nom de POD . Un pod peut héberger plusieurs conteneurs et volumes de stockage différents. Chaque pod a également son adresse IP unique. Il est également ultra évolutif car basé sur des plans de déploiement (fichier yaml).

Nœuds

Pour garder les choses simples pour tout le monde, nous allons simplement décomposer le type de nœuds en :

● Nœuds de travail

● Nœud maître

Un ensemble de nœuds forme un cluster.

Nœuds de travail :

Les pods résident sur ces nœuds de travail qui peuvent être des machines virtuelles ou physiques. Vous pouvez les considérer comme des machines hôtes pour les pods.

Nœud maître :

Un nœud maître est l'administrateur ultime de l'ensemble du cluster. Il contrôle et gère tous les nœuds de travail, qui incluent les composants suivants : serveur Kube-API, Kube-Controller-Manager, Kube Scheduler, etc.

Espace de noms

Un espace de noms Kubernetes est un mécanisme d'isolation qui isole les ressources au sein d'un cluster, généralement utilisé lorsque différentes équipes travaillent sur le même cluster. Dans le contexte de la cybersécurité, chaque objet/ressource d'espace de noms est unique à l'espace de noms. L'appel d'objet/ressource entre espaces de noms est impossible car ces objets/ressources sont isolés dans leurs espaces de noms.

Maintenant, avec toutes ces nouvelles connaissances, vous devriez avoir une compréhension fondamentale de l'environnement Kubernetes. Passons au côté plus juteux des choses, comment s'attaquer à Kubernetes ?

Méthodologie d'attaque

La méthodologie d'un attaquant sophistiqué peut être décomposée en trois étapes.

Étape 1 : Prise de pied initiale

Le principal moyen de prendre pied consiste à compromettre une application Web ou un microservice hébergé sur le cluster. L'objectif de l'attaquant est d'obtenir l'exécution de code à distance sur l'application en énumérant l'application et en identifiant les vulnérabilités exploitables (par exemple log4shell, apache struts).

Étape 2 : Escalade des privilèges

En prenant pied dans le cluster Kubernetes, un attaquant se trouverait à l'intérieur d'un pod, qui, comme expliqué, est simplement un conteneur docker. Un attaquant pourrait renifler le conteneur à la recherche de données sensibles, mais est limité à ce qui est disponible. . En tant que tel, l'attaquant cherchera à escalader soit un pod avec plus de privilèges, soit un nœud.

Voici quelques techniques courantes qu'un attaquant emploierait :

• Fichiers sensibles

Correction :

En plus de la pratique standard consistant à ne pas laisser les informations d'identification sensibles non chiffrées dans un pod, un administrateur Kubernetes doit adhérer aux principes du moindre privilège lorsqu'il accorde des privilèges au jeton de compte de service.

• Applications accessibles

Correction :

Pour gérer quels pods, espaces de noms ou même serveurs externes peuvent atteindre une ressource Kubernetes particulière, un administrateur Kubernetes peut utiliser la ressource de stratégie réseau Kubernetes .

• Services de métadonnées cloud

Correction :

L'administrateur Kubernetes peut utiliser la ressource de stratégie réseau Kubernetes susmentionnée pour empêcher un attaquant d'atteindre l'API de métadonnées cloud et d'autres applications hébergées dans le cluster non requises pour les fonctions commerciales principales.

• Évasion des gousses

Correction :

L'administrateur Kubernetes peut utiliser la ressource de contrôleur d'admission, une ressource Kubernetes qui valide chaque ressource créée dans le cluster Kubernetes par un ensemble de règles défini. Une ressource non conforme à l'ensemble de règles défini échouerait à être créée, ce qui entraînerait une erreur.

Étape 3 : Obtenir les joyaux de la couronne

Dans l'écosystème Kubernetes, les joyaux de la couronne font référence au nœud maître. Un attaquant qui a obtenu un accès complet au nœud maître aurait essentiellement le contrôle complet du cluster Kubernetes. L'attaquant répéterait les techniques détaillées aux étapes 1 et 2, pour passer latéralement d'un pod infecté au nœud sous-jacent, puis enfin au nœud maître. Pour éviter que ce pire scénario ne se produise, un administrateur Kubernetes doit s'assurer que le cluster est configuré de manière sécurisée avec certaines des corrections mentionnées ci-dessus.

Est-ce tout?

Pour un aperçu plus complet de la posture de sécurité Kubernetes de votre organisation, nous vous recommandons d'utiliser la matrice d'attaque Kubernetes de Microsoft. La matrice comprend les principales tactiques pertinentes pour la sécurité de Kubernetes. Chacun d'eux contient plusieurs techniques que les attaquants peuvent utiliser pour atteindre différents objectifs.

Conclusion

Alors que de plus en plus d'organisations adoptent Kubernetes comme outil de facto pour gérer l'orchestration des conteneurs, des données plus sensibles se retrouveront sur les clusters Kubernetes. Les administrateurs système ont encore plus besoin de configurer leur cluster pour le configurer en toute sécurité. Un attaquant disposant d'un accès complet au nœud maître d'un cluster Kubernetes est la dernière chose qu'un CISO voudrait voir.

Surveillez nos prochains articles, où nous partagerons des attaques plus approfondies et spécifiques que nous voyons couramment sur le terrain aujourd'hui.

Prenez soin de vous et rattrapez-vous sur le FLIPPETY-FLIP.