Comment sécuriser les clusters Kubernetes avec le Cloud Penetration Testing

Kubernetes est devenu en quelque sorte le système d'exploitation du cloud. Si vous exécutez des conteneurs à grande échelle, vous utilisez presque certainement K8s. C'est puissant, c'est flexible et cela gère l'orchestration comme dans un rêve. Mais voici le hic : cette même puissance s'accompagne d'une énorme complexité. Lorsque vous passez d'une configuration traditionnelle basée sur des machines virtuelles à une couche d'orchestration conteneurisée, votre surface d'attaque ne se contente pas de se déplacer, elle s'étend dans des directions que vous ne regardez peut-être même pas.

La plupart des équipes commencent leur parcours Kubernetes en suivant quelques tutoriels de base, en lançant un cluster sur EKS, GKE ou AKS, et en déployant leurs applications. Tout fonctionne. Ensuite, ils ajoutent des espaces de noms, quelques contrôleurs d'entrée et peut-être un contrôle d'accès basé sur les rôles (RBAC) de base. Cela semble sûr. Mais « ça marche » et « c'est sûr » sont deux choses très différentes dans le monde de l'infrastructure cloud-native. Un seul fichier YAML mal configuré ou un ServiceAccount sur-privilégié peut faire la différence entre un environnement de production sécurisé et une prise de contrôle totale du cluster.

C'est là que le cloud pentesting entre en jeu. Vous ne pouvez pas simplement exécuter un scanner de réseau standard sur un cluster Kubernetes et en rester là. K8s possède son propre réseau interne, son propre serveur API et son propre ensemble d'excentricités de gestion des identités. Pour réellement sécuriser un cluster, vous devez penser comme un attaquant. Vous devez vous demander : « Si je compromets un pod, puis-je atteindre le serveur API ? Puis-je voler un jeton du système de fichiers ? Puis-je me déplacer latéralement vers un autre espace de noms ? »

Dans ce guide, nous allons plonger en profondeur dans la réalité de la sécurisation de Kubernetes. Nous allons dépasser les conseils génériques du type « utilisez des mots de passe forts » et examiner les vecteurs d'attaque réels qui empêchent les ingénieurs de sécurité de dormir la nuit. Plus important encore, nous allons explorer comment une approche cloud-native du Penetration Testing, comme ce que nous avons construit chez Penetrify, vous permet de trouver ces failles avant que quelqu'un d'autre ne le fasse.

Comprendre la surface d'attaque de Kubernetes

Avant de parler de la façon de tester le cluster, nous devons comprendre ce que nous testons réellement. Kubernetes n'est pas une seule chose ; c'est un ensemble de composants qui doivent tous communiquer entre eux. Si l'un de ces canaux de communication est ouvert ou mal authentifié, tout le château de cartes peut s'effondrer.

Le plan de contrôle : le cerveau du cluster

Le plan de contrôle est la principale cible de tout attaquant sérieux. Pourquoi ? Parce que si vous contrôlez le serveur API, vous contrôlez tout. Le kube-apiserver est la passerelle pour toutes les tâches administratives. S'il est exposé à l'Internet public sans authentification stricte, ou s'il existe une vulnérabilité dans la version que vous exécutez, un attaquant peut essentiellement envoyer des commandes à votre cluster comme s'il était l'administrateur.

Ensuite, vous avez etcd. Il s'agit de la base de données du cluster. Il stocke tout : les secrets, les cartes de configuration et l'état de chaque pod. Si un attaquant accède à etcd, il n'a même pas besoin de parler au serveur API ; il peut simplement lire vos secrets directement depuis le disque.

Les nœuds de travail et le Kubelet

Les nœuds de travail sont l'endroit où votre code réel s'exécute. Le kubelet est l'agent qui s'exécute sur chaque nœud et qui communique avec le plan de contrôle. Une erreur courante consiste à laisser l'API Kubelet ouverte ou à autoriser l'accès non authentifié. Si je peux parler à un Kubelet, je pourrais être en mesure d'exécuter des commandes à l'intérieur d'un pod ou même d'extraire des informations sensibles sur l'environnement du nœud.

Les pods et les conteneurs

C'est le point d'entrée le plus courant. La plupart des attaques commencent par une vulnérabilité dans le code de l'application : peut-être une RCE de style Log4j ou une simple SQL Injection. Une fois que l'attaquant est à l'intérieur d'un conteneur, il commence à « s'échapper du pod ». Il cherche des moyens de sortir du conteneur et d'accéder au nœud hôte sous-jacent. De là, il recherche le jeton ServiceAccount généralement monté sur /var/run/secrets/kubernetes.io/serviceaccount/token.

La couche réseau (CNI)

La mise en réseau Kubernetes est souvent un réseau « plat » par défaut. Cela signifie que, par défaut, n'importe quel pod du cluster peut communiquer avec n'importe quel autre pod, quel que soit l'espace de noms. Si votre serveur Web frontal est compromis, il peut potentiellement envoyer des requêtes à votre API de traitement des paiements interne ou à votre base de données sans aucun pare-feu unique entre les deux.

Les erreurs de configuration courantes de Kubernetes qui mènent à des violations

Lorsque nous effectuons des Penetration Testing chez Penetrify, nous trouvons rarement des vulnérabilités « Zero Day » dans le code de base de Kubernetes. Au lieu de cela, nous trouvons des erreurs « Zero Day » dans la façon dont le cluster a été configuré. Ce sont les fruits à portée de main que les attaquants adorent.

Rôles RBAC sur-privilégiés

Le contrôle d'accès basé sur les rôles (RBAC) est la partie la plus mal comprise de la sécurité K8s. Il est très facile d'être frustré par les erreurs « Autorisation refusée » lors du déploiement et de simplement attribuer le rôle cluster-admin à un ServiceAccount.

Imaginez un simple pod de surveillance qui n'a besoin que de lister les pods pour vérifier leur état de santé. Si ce pod reçoit les autorisations cluster-admin et que l'application à l'intérieur est compromise, l'attaquant a maintenant le contrôle total sur l'ensemble du cluster. Il peut supprimer des espaces de noms, voler des secrets et déployer ses propres pods malveillants (comme des mineurs de crypto).

Le piège du conteneur « privilégié »

L'exécution d'un conteneur en tant que privileged: true indique essentiellement à Kubernetes de désactiver la plupart des limites de sécurité entre le conteneur et l'hôte. Un conteneur privilégié a presque le même accès au noyau hôte qu'un processus s'exécutant directement sur le nœud. Pour un pentester, un conteneur privilégié est un ticket d'or. Il rend l'évasion vers l'hôte triviale, ce qui lui permet d'accéder au socket Docker ou à l'API Kubelet.

Tableau de bord et serveur API exposés

Le tableau de bord Kubernetes est excellent pour la visibilité, mais c'est un cauchemar s'il n'est pas sécurisé. Nous avons vu des clusters où le tableau de bord était exposé à Internet avec un compte de service par défaut qui avait des privilèges d'administration. C'est essentiellement une interface graphique web pour détruire votre propre infrastructure. De même, laisser le serveur API ouvert à 0.0.0.0/0 sans MFA ou liste blanche d'IP stricte est une recette pour le désastre.

Secrets non protégés

De nombreuses équipes stockent des "secrets" dans des objets Kubernetes Secrets. Bien que cela semble correct, rappelez-vous que par défaut, les secrets K8s sont uniquement encodés en base64, et non chiffrés. Toute personne ayant accès à l'API ou à la base de données etcd peut les décoder en quelques secondes. Si vous n'utilisez pas un KMS (Key Management Service) dédié ou un outil comme HashiCorp Vault, vos secrets ne sont pas réellement secrets.

Le flux de travail de Cloud Penetration Testing pour Kubernetes

Le Penetration Testing traditionnel est souvent un événement "ponctuel" : un consultant vient pendant deux semaines, rédige un rapport et repart. Mais les environnements Kubernetes changent chaque fois que vous exécutez kubectl apply. Vous avez besoin d'une approche plus continue et native du cloud pour les tests.

Phase 1 : Reconnaissance et cartographie externe

La première étape d'un cloud pentest consiste à voir ce que le monde voit. Nous commençons par rechercher les points de terminaison exposés.

Le serveur API est-il accessible ?
Y a-t-il un port Kubelet (10250) ouvert ?
Existe-t-il des tableaux de bord ou des pages de métriques Prometheus exposés ?
Quelles règles d'entrée autorisent le trafic vers le cluster ?

Phase 2 : Accès initial (l'"empreinte")

Une fois que nous avons trouvé un point d'entrée, par exemple une application web vulnérable, nous établissons une tête de pont. Cela implique généralement d'obtenir un shell inversé. Mais une fois que nous sommes à l'intérieur, l'objectif passe de "attaquer l'application" à "attaquer le cluster".

La première chose qu'un pentester fait est de vérifier le jeton ServiceAccount : cat /var/run/secrets/kubernetes.io/serviceaccount/token

Si ce jeton existe, nous pouvons l'utiliser pour nous authentifier auprès du serveur API depuis l'intérieur du pod.

Phase 3 : Énumération interne et élévation de privilèges

Maintenant, nous demandons : "Que puis-je réellement faire avec ce jeton ?" Nous utilisons des outils comme kubectl auth can-i --list pour voir nos permissions.

Si nous avons les permissions pour create pods, nous pouvons lancer un pod "malveillant" qui monte le système de fichiers racine de l'hôte. Si nous avons les permissions pour get secrets, nous pouvons vider chaque mot de passe et clé API dans l'espace de noms. C'est là que le "jeu d'échecs" de la sécurité Kubernetes se déroule : passer d'un pod à faibles privilèges à un nœud à privilèges élevés.

Phase 4 : Mouvement latéral

Si le cluster n'a pas de Network Policies (la version K8s d'un pare-feu), nous pouvons nous déplacer latéralement. Nous scannons le réseau interne des pods pour trouver d'autres services. Nous pourrions trouver un cache Redis non authentifié ou une base de données interne qui fait confiance à toute connexion provenant de l'intérieur du cluster.

Phase 5 : Exfiltration et persistance

La dernière étape consiste à voir si nous pouvons voler des données ou maintenir l'accès. Pouvons-nous créer un Deployment de "porte dérobée" qui se redémarre s'il est supprimé ? Pouvons-nous voler les métadonnées IAM du fournisseur de cloud à partir du nœud (par exemple, accéder à 169.254.169.254 sur AWS) pour passer du cluster Kubernetes au compte AWS plus large ?

Étapes pratiques pour renforcer votre cluster

Si vous avez lu jusqu'ici et que vous vous dites : "Mon cluster pourrait être vulnérable", ne paniquez pas. La sécurité est un processus d'amélioration continue. Voici une liste de contrôle pratique pour faire passer votre cluster de "standard" à "renforcé".

1. Mettre en œuvre des Network Policies strictes

Cessez de supposer que le réseau interne est sûr. Par défaut, mettez en œuvre une politique de "tout refuser" pour le trafic entrant et sortant dans vos espaces de noms. Ensuite, autorisez explicitement uniquement les connexions nécessaires.

Le pod A ne doit parler au pod B que sur le port 8080.
Le pod B ne doit parler à la base de données que sur le port 5432.
Empêchez tous les pods de parler à l'API de métadonnées du cloud, sauf s'ils en ont absolument besoin.

2. Nettoyez votre RBAC

Vérifiez vos rôles. Cessez d'utiliser cluster-admin pour tout.

Utilisez des Namespaced Roles au lieu de ClusterRoles dans la mesure du possible.
Suivez le principe du moindre privilège (PoLP). Si un pod n'a besoin que de lire un ConfigMap, ne lui donnez pas la possibilité de le mettre à jour.
Vérifiez régulièrement qui a accès au cluster à l'aide d'outils tels que rbac-lookup.

3. Utilisez les Pod Security Admissions (PSA)

Cessez d'autoriser les conteneurs privilégiés. Kubernetes dispose de Pod Security Admissions intégrés qui vous permettent d'appliquer différents niveaux de sécurité :

Privileged : Illimité (en gros, "faites ce que vous voulez"). Évitez cela en production.
Baseline : Empêche les élévations de privilèges connues.
Restricted : Applique une norme de sécurité très élevée (pas d'utilisateurs root, pas d'accès au réseau hôte).

Viser le profil restricted pour toutes vos charges de travail d'application.

4. Sécurisez vos secrets

Éloignez-vous des secrets K8s encodés en base64.

Activez le chiffrement au repos pour votre base de données etcd.
Utilisez un gestionnaire de secrets natif du cloud. Par exemple, utilisez AWS Secrets Manager ou Azure Key Vault et intégrez-les à vos pods à l'aide du Secret Store CSI Driver. Cela garantit que les secrets sont injectés dans le pod au moment de l'exécution et ne sont jamais stockés en texte clair dans l'API K8s.

5. Gardez vos composants à jour

Cela semble basique, mais c'est là que de nombreuses violations se produisent. Les vulnérabilités dans kube-apiserver ou kubelet sont corrigées rapidement, mais si vous exécutez une version d'il y a deux ans, vous êtes une cible facile. Automatisez les mises à niveau de votre cluster pour rester à jour avec les derniers correctifs de sécurité.

Une comparaison : Penetration Testing manuel vs. Analyse automatisée vs. Plateformes natives du cloud

Beaucoup de gens demandent : "Ne puis-je pas simplement exécuter un scanner de vulnérabilités ?" La réponse est oui, mais un scanner n'est pas un Penetration Test. Voici la différence.

Fonctionnalité	Scanner de vulnérabilités automatisé	Pentest manuel traditionnel	Plateforme native du cloud (Penetrify)
Portée	Trouve les CVE connus dans les paquets.	Plongée en profondeur dans la logique et la configuration.	Combine l'analyse des CVE avec l'analyse de la configuration.
Contexte	Ne comprend pas RBAC ou le flux réseau.	Comprend le contexte mais est lent.	Cartographie la surface d'attaque en temps réel.
Fréquence	Peut fonctionner quotidiennement.	Une ou deux fois par an.	Continu et à la demande.
Applicabilité	Donne une longue liste de bugs "potentiels".	Donne un rapport détaillé.	Fournit des chemins de correction et s'intègre à SIEM.
Coût	Faible à modéré.	Élevé (honoraires de consultant).	Abonnement évolutif.

Les scanners sont parfaits pour trouver une version de Nginx qui a un bug. Mais un scanner ne vous dira pas que votre politique RBAC permet au pod d'un développeur de supprimer votre base de données de production. Un pentester manuel trouvera cela, mais il est coûteux et ne peut pas être partout à la fois.

Une plateforme comme Penetrify comble cette lacune. Elle utilise une architecture native du cloud pour simuler ces attaques automatiquement et de manière cohérente, vous offrant la profondeur d'un pentest avec la vitesse d'un scanner.

Scénario avancé : l'évasion « Pod-to-Cloud »

Pour vraiment comprendre pourquoi le cloud Penetration Testing est différent, examinons un scénario d'attaque réaliste. Il s'agit d'un chemin courant que nous trouvons lors des évaluations.

Étape 1 : L'entrée Un attaquant trouve une vulnérabilité Server-Side Request Forgery (SSRF) dans une application Django publique s'exécutant dans un pod Kubernetes.

Étape 2 : L'accès aux métadonnées L'attaquant utilise la vulnérabilité SSRF pour accéder au point de terminaison des métadonnées du fournisseur de cloud : http://169.254.169.254/latest/meta-data/iam/security-credentials/. Étant donné que le rôle IAM du nœud est surprivilégié, l'attaquant récupère une clé d'accès AWS temporaire.

Étape 3 : Analyse du compte À l'aide de ces clés, l'attaquant se rend compte qu'il dispose des autorisations S3:ListBucket et S3:GetObject pour l'ensemble du compte AWS. Il trouve un bucket contenant des sauvegardes de la base de données de production.

Étape 4 : La prise de contrôle du cluster En explorant le bucket S3, il trouve une sauvegarde d'un fichier kubeconfig qui a été téléchargé accidentellement. Ce fichier contient un certificat pour un utilisateur cluster-admin.

Étape 5 : Contrôle total L'attaquant utilise le fichier kubeconfig pour se connecter au serveur API depuis son propre ordinateur portable. Il a désormais un pouvoir absolu sur le cluster. Il déploie un tunnel chiffré (comme Ngrok) à l'intérieur du cluster pour maintenir une porte dérobée permanente, contournant tous les pare-feu de périmètre.

La leçon ? La vulnérabilité ne se trouvait pas seulement dans l'application Django. Il s'agissait d'une chaîne : SSRF $\rightarrow$ IAM de nœud surprivilégié $\rightarrow$ Secret divulgué dans S3 $\rightarrow$ Kubeconfig d'administrateur. Un simple scanner de pod n'aurait trouvé que la vulnérabilité Django ; il ne vous aurait pas montré que l'ensemble de votre compte AWS était menacé.

Intégration de la sécurité dans le pipeline CI/CD (DevSecOps)

Vous ne pouvez pas simplement « faire » de la sécurité à la fin. Au moment où un pentester trouve un trou dans votre cluster de production, les dommages (ou le coût de sa correction) sont déjà élevés. Vous devez déplacer la sécurité vers la « gauche ».

Tests Shift-Left

Intégrez des contrôles de sécurité dans vos pipelines GitLab ou GitHub.

Analyse statique (SAST) : analysez vos Dockerfiles pour « USER root » et vos fichiers YAML pour privileged: true.
Analyse d'image : utilisez des outils pour vous assurer que vos images de base ne présentent pas de CVE connus avant même d'atteindre le registre.
Policy as Code : utilisez OPA (Open Policy Agent) ou Kyverno. Ces outils agissent comme des contrôleurs d'admission. Si un développeur tente de déployer un pod qui n'a pas de limites de ressources ou qui s'exécute en tant que root, le cluster rejette simplement le déploiement.

La boucle de rétroaction

La vraie magie opère lorsque vous reconnectez les résultats de votre Penetration Testing à votre cycle de développement. Lorsqu'une plateforme comme Penetrify identifie une mauvaise configuration dans votre cluster de développement, cet aperçu doit automatiquement créer un ticket dans Jira pour que l'équipe puisse le corriger.

La sécurité ne doit pas être une « porte » qui arrête le déploiement ; elle doit être un « garde-fou » qui guide le déploiement. Lorsque les développeurs savent exactement pourquoi une certaine configuration est dangereuse (parce qu'un Penetration Test a simulé une attaque et l'a prouvé), ils sont beaucoup plus susceptibles d'écrire du code sécurisé dès le départ.

Erreurs courantes lors de la sécurisation de Kubernetes

Même les équipes expérimentées trébuchent sur ces erreurs. Si vous gérez un cluster, vérifiez si vous faites l'une de ces choses.

Erreur 1 : Faire confiance à l'étiquette « Géré par le cloud »

Beaucoup de gens supposent que parce qu'ils utilisent EKS ou GKE, Google ou Amazon gèrent la sécurité. Bien que le fournisseur de cloud sécurise le plan de contrôle (les nœuds maîtres), vous êtes toujours responsable du plan de données (vos nœuds de travail, vos pods et vos politiques de réseau). Le « Modèle de responsabilité partagée » est réel. Si vous laissez votre serveur API ouvert, AWS n'empêchera pas un attaquant d'entrer.

Erreur 2 : Ignorer l'espace de noms « Par défaut »

L'espace de noms default est souvent un dépotoir pour les tests et les pods aléatoires. De nombreuses équipes oublient d'appliquer les mêmes politiques strictes RBAC et réseau à l'espace de noms default qu'à l'environnement production. Un attaquant qui pénètre dans un pod de "test" dans l'espace de noms par défaut peut souvent l'utiliser comme point de départ pour attaquer d'autres parties du cluster.

Erreur 3 : Dépendance excessive à l'analyse d'images

Analyser une image à la recherche de CVE est important, mais ce n'est pas suffisant. Une image peut avoir zéro vulnérabilité connue, mais être configurée pour s'exécuter en tant que root avec un accès complet à l'espace de noms PID de l'hôte. Vous devez sécuriser la configuration d'exécution, et pas seulement le binaire.

Erreur 4 : Oublier de journaliser et de surveiller

Vous ne pouvez pas arrêter une attaque que vous ne pouvez pas voir. De nombreuses équipes oublient d'activer les journaux d'audit Kubernetes. Les journaux d'audit vous indiquent qui a fait quoi, quand et comment. Sans eux, si un attaquant vole un jeton et crée une porte dérobée, vous n'aurez aucune trace de la façon dont cela s'est produit.

FAQ : Sécuriser Kubernetes avec le Cloud Penetration Testing

Q : À quelle fréquence dois-je effectuer un Penetration Test sur mon cluster Kubernetes ? R : Cela dépend de votre fréquence de changement. Si vous poussez du code quotidiennement, un Penetration Test une fois par an est inutile. Vous devriez avoir une analyse automatisée quotidiennement et un Penetration Testing approfondi tous les trimestres ou après chaque changement architectural majeur. Les plateformes natives du cloud permettent un "Penetration Testing continu", qui est la référence absolue.

Q : Dois-je installer des agents sur mes nœuds pour le Cloud Penetration Testing ? R : Pas nécessairement. De nombreuses plateformes modernes, y compris Penetrify, utilisent une combinaison d'analyse basée sur l'API et de "pods d'attaquants" contrôlés pour simuler des menaces sans avoir besoin d'installer des agents invasifs sur chaque nœud. Cela réduit la surcharge de performance et le risque de sécurité de l'outil de test lui-même.

Q : Le Penetration Testing peut-il casser mon cluster de production ? R : Il y a toujours un risque avec tout test actif. C'est pourquoi nous recommandons de tester dans un environnement de staging qui reflète la production. Cependant, les outils professionnels de Cloud Penetration Testing sont conçus pour être non destructifs. Ils recherchent une "preuve de concept" d'accès (comme la lecture d'un fichier) plutôt que d'effectuer des attaques de "déni de service".

Q : Quelle est la différence entre une analyse de vulnérabilité et un Penetration Test ? R : Une analyse est comme un système de sécurité domestique qui vérifie si les portes sont verrouillées. Un Penetration Test revient à embaucher quelqu'un pour essayer de s'introduire dans votre maison. Le scanner vous indique que la porte pourrait être ouverte ; le pentester franchit réellement la porte et vous dit qu'il peut atteindre votre boîte à bijoux dans la chambre.

Q : RBAC est-il suffisant pour sécuriser un cluster ? R : Non. RBAC n'est qu'une seule couche. Vous avez également besoin de Network Policies (pour arrêter les mouvements latéraux), de Pod Security Admissions (pour arrêter les évasions) et de Secret Management (pour protéger les données sensibles). Considérez cela comme une "défense en profondeur".

Principaux points à retenir et prochaines étapes

Sécuriser Kubernetes ne consiste pas à cocher une seule case ; il s'agit de réduire le "rayon d'explosion". Vous devez supposer qu'à un moment donné, un pod sera compromis. L'objectif est de s'assurer que, lorsque cela se produit, l'attaquant se retrouve dans une pièce fermée à clé, sans clé et sans moyen de communiquer avec le reste de la maison.

Si vous vous sentez dépassé, commencez par ces trois actions immédiates :

Auditez votre RBAC : Trouvez chaque ServiceAccount avec cluster-admin et déterminez s'il en a réellement besoin. (Indice : probablement pas).
Activez les Network Policies : Commencez par bloquer tout le trafic de sortie de vos pods vers l'API de métadonnées du cloud (169.254.169.254).
Effectuez un test réel : Arrêtez de deviner si vous êtes en sécurité. Utilisez un outil ou un service pour simuler réellement une attaque.

La complexité de Kubernetes est sa plus grande force, mais aussi sa plus grande faiblesse. La seule façon de vraiment connaître votre posture est de la tester dans des conditions réelles.

Si vous voulez arrêter de deviner et commencer à savoir, Penetrify peut vous aider. Nous fournissons l'infrastructure native du cloud pour exécuter des évaluations de sécurité de qualité professionnelle sans la surcharge massive du conseil traditionnel. Nous vous aidons à trouver les lacunes dans votre RBAC, les trous dans vos Network Policies et les chemins d'escalade de privilèges avant qu'un acteur malveillant ne le fasse.

N'attendez pas une violation pour découvrir que votre cluster "sécurisé" avait une porte grande ouverte. Visitez Penetrify.cloud dès aujourd'hui et obtenez une vue claire et exploitable de votre posture de sécurité.

Retour au blog