Sécurisez vos clusters Kubernetes avec le Cloud Penetration Testing

Kubernetes est devenu la référence en matière d'orchestration de conteneurs. C'est un outil puissant, il s'adapte magnifiquement et il permet aux développeurs de livrer du code plus rapidement que jamais. Mais soyons honnêtes : Kubernetes est aussi incroyablement complexe. Entre le serveur API, etcd, kubelet, les pods et une montagne de fichiers YAML, il y a beaucoup d'endroits où les choses peuvent mal tourner. Un simple paramètre de contrôle d'accès basé sur les rôles (Role-Based Access Control ou RBAC) mal configuré ou un compte de service sur-privilégié peut transformer un bug mineur en une prise de contrôle complète du cluster.

La plupart des équipes commencent avec une configuration "par défaut", pensant que le service géré du fournisseur de cloud a tout verrouillé. Bien que GKE, EKS et AKS fournissent une base de référence décente, ils ne corrigent pas comme par magie vos vulnérabilités au niveau de l'application ou vos erreurs de configuration personnalisées. La réalité est que la "surface d'attaque" d'un cluster Kubernetes est massive. Vous ne sécurisez pas seulement un serveur ; vous sécurisez un système distribué de microservices interconnectés.

C'est là que le cloud pentesting entre en jeu. Les analyses de sécurité traditionnelles passent souvent à côté des façons nuancées dont un attaquant peut se déplacer latéralement au sein d'un cluster. Vous avez besoin d'une approche proactive qui simule la façon dont un véritable attaquant pense, en partant d'un pod compromis et en essayant d'atteindre le nœud ou l'API de métadonnées du fournisseur de cloud. Au moment où un scanner de vulnérabilités signale une CVE, un attaquant averti pourrait déjà avoir utilisé une permission mal configurée pour escalader ses privilèges.

Dans ce guide, nous allons plonger en profondeur dans les spécificités de la sécurisation de Kubernetes. Nous examinerons les vecteurs d'attaque les plus courants, comment renforcer vos clusters et pourquoi l'utilisation d'une plateforme basée sur le cloud comme Penetrify peut vous aider à trouver ces failles avant que quelqu'un d'autre ne le fasse.

Comprendre la surface d'attaque de Kubernetes

Pour sécuriser un cluster, vous devez d'abord comprendre comment il peut être cassé. Kubernetes n'est pas un monolithe ; c'est un ensemble de composants qui communiquent entre eux. Si l'un de ces canaux de communication est ouvert ou fait trop confiance, vous avez un problème.

Le plan de contrôle : le cerveau de l'opération

Le plan de contrôle est la cible principale de tout attaquant. S'ils accèdent au serveur API, c'est la fin de la partie. Ils peuvent déployer des pods malveillants, voler des secrets ou supprimer toute votre infrastructure. Les problèmes les plus courants ici sont :

Accès API non authentifié : Cela arrive plus souvent qu'on ne le pense. Quelqu'un laisse le serveur API ouvert à l'internet public pour le "débogage" et oublie de le fermer.
Politiques RBAC faibles : Donner des privilèges cluster-admin à un développeur qui n'a besoin que de consulter les logs est une recette pour le désastre.
etcd exposé : etcd est la base de données où tout l'état du cluster est stocké. Si un attaquant atteint etcd directement, il peut contourner complètement le serveur API et réécrire la réalité du cluster.

Le plan de données : là où le travail se fait

C'est là que vivent vos pods et vos nœuds. Alors que le plan de contrôle est le cerveau, le plan de données est le corps. Les attaquants essaient souvent de prendre pied ici en premier.

Container Escape : Si un conteneur est exécuté en tant que root ou a un accès privilégié, un attaquant peut "s'échapper" du conteneur et accéder au nœud hôte sous-jacent.
Communication Pod-to-Pod : Par défaut, Kubernetes ne bloque pas le trafic entre les pods. Si un attaquant compromet un petit pod exposé au web, il peut soit renifler le trafic, soit attaquer tous les autres pods du cluster.
Gestion non sécurisée des secrets : Stocker des mots de passe ou des clés API en texte clair dans un ConfigMap ou même utiliser des Secrets K8s de base (qui sont juste encodés en base64) est une erreur courante.

L'élément humain et CI/CD

Nous oublions souvent que le cluster est géré par des personnes et des pipelines.

Fichiers Kubeconfig divulgués : Un développeur pousse accidentellement son fichier .kube/config vers un dépôt GitHub public, et soudain, le monde entier a un accès administrateur à votre cluster de production.
Images empoisonnées : Utiliser une image non vérifiée de Docker Hub qui contient une porte dérobée.
Vulnérabilités du pipeline : Attaquants ciblant le runner Jenkins ou GitLab qui a les permissions de déployer sur le cluster.

Vulnérabilités Kubernetes courantes et comment les exploiter (et les arrêter)

C'est une chose de lire une liste de risques ; c'en est une autre de comprendre comment ils se déroulent réellement. Examinons quelques scénarios réels.

Scénario 1 : Le compte de service sur-privilégié

Imaginez un pod exécutant un simple agent de surveillance. Pour une raison quelconque, le développeur lui a donné un ServiceAccount avec un ClusterRole qui lui permet de list et get des secrets dans tout l'espace de noms.

L'attaque :

Un attaquant trouve un bug d'exécution de code à distance (RCE) dans l'agent de surveillance.
Ils trouvent le jeton du compte de service monté à /var/run/secrets/kubernetes.io/serviceaccount/token.
En utilisant kubectl, ils utilisent ce jeton pour interroger le serveur API : kubectl get secrets.
Ils trouvent le mot de passe de la base de données et les clés d'accès du fournisseur de cloud.

La correction : Mettre en œuvre le Principe du moindre privilège. Utilisez des Roles spécifiques au lieu de ClusterRoles chaque fois que possible. Utilisez des outils comme audit2rbac pour analyser les permissions qui sont réellement utilisées et supprimer le reste.

Scénario 2 : L'évasion de conteneur privilégié

Une équipe déploie un outil de logging qui nécessite le mode "privilégié" pour voir les interfaces réseau de l'hôte.

L'attaque :

L'attaquant compromet le pod de journalisation.
Étant donné que le pod est privilégié, il peut voir les périphériques de l'hôte.
Il monte le système de fichiers racine de l'hôte (/) dans le conteneur.
Il crée une tâche cron sur l'hôte ou ajoute une nouvelle clé SSH au fichier authorized_keys de l'hôte.
Il a maintenant un accès root complet au nœud. De là, il peut potentiellement accéder à d'autres pods sur le même nœud.

La solution : Évitez privileged: true à tout prix. Si vous avez besoin de capacités spécifiques (comme NET_ADMIN), n'accordez que ces capacités spécifiques en utilisant le bloc capabilities dans le contexte de sécurité. Utilisez un contrôleur Pod Security Admission (PSA) pour appliquer les politiques « Baseline » ou « Restricted ».

Scénario 3 : La fuite de l'API de métadonnées

Dans les environnements cloud (AWS, GCP, Azure), les pods peuvent souvent atteindre le service de métadonnées cloud (par exemple, 169.254.169.254).

L'attaque :

Un attaquant obtient l'accès à un pod.
Il effectue une requête curl sur le point de terminaison des métadonnées : curl http://169.254.169.254/latest/meta-data/iam/security-credentials/.
Le service de métadonnées renvoie les informations d'identification AWS temporaires pour le rôle IAM attaché au nœud de travail.
L'attaquant utilise ces informations d'identification pour accéder aux buckets S3 ou modifier les paramètres VPC.

La solution : Utilisez des Network Policies pour bloquer tout le trafic de sortie vers l'adresse IP des métadonnées. Alternativement, utilisez un accès basé sur l'identité comme AWS IRSA (IAM Roles for Service Accounts) ou Azure Pod Identity afin que les pods obtiennent leurs propres identités limitées au lieu d'hériter de l'identité du nœud.

Pourquoi l'analyse traditionnelle ne suffit pas

Vous avez probablement utilisé un scanner de vulnérabilités. Il vous indique que votre image Alpine Linux a trois CVE de gravité moyenne. C'est utile, mais ce n'est pas de la « sécurité ».

L'analyse est passive. Le Penetration Testing est actif.

Un scanner peut vous dire qu'une bibliothèque est obsolète. Il ne peut pas vous dire que votre configuration RBAC permet à un développeur de supprimer accidentellement la base de données de production. Il ne peut pas vous dire qu'un attaquant peut utiliser une chaîne spécifique de mauvaises configurations pour passer d'un pod frontal à l'administrateur du cluster.

Le cloud Penetration Testing implique la « chaîne d'exploitation ». Un attaquant ne se contente pas de trouver un seul bug ; il trouve une séquence de petites erreurs qui, combinées, conduisent à une compromission totale.

Par exemple :

Étape 1 : Trouver une image obsolète (le scanner trouve ceci).
Étape 2 : Utiliser cette image pour obtenir un shell (le scanner ne peut pas faire cela).
Étape 3 : Trouver un token divulgué dans le système de fichiers (le scanner pourrait manquer cela).
Étape 4 : Utiliser le token pour pivoter vers un pod plus privilégié (le scanner ne peut certainement pas faire cela).

C'est pourquoi les entreprises se tournent vers des évaluations de sécurité continues. Au lieu d'un audit annuel, elles utilisent des plateformes natives du cloud pour simuler ces attaques en permanence. Penetrify simplifie cela en fournissant un environnement géré où ces simulations peuvent avoir lieu sans que vous ayez besoin de construire votre propre « laboratoire d'attaque ».

Un guide étape par étape pour renforcer votre cluster Kubernetes

Si vous êtes face à un cluster complexe et que vous ne savez pas par où commencer, suivez cette liste de contrôle. Nous passerons des « gains faciles » aux changements architecturaux plus complexes.

Phase 1 : Les fruits à portée de main (gains faciles)

Désactiver le montage automatique du token du compte de service par défaut : Par défaut, K8s monte un token dans chaque pod. La plupart des pods n'ont pas besoin de communiquer avec le serveur API. Définissez automountServiceAccountToken: false dans votre PodSpec.
Mettez à jour vos images : Utilisez un outil comme Trivy ou Grype pour scanner vos images pendant le pipeline CI/CD. Si une image présente une vulnérabilité de haute gravité, faites échouer la construction.
Supprimez les permissions inutiles : Auditez vos ClusterRoles. Si vous voyez * dans les champs resources ou verbs, c'est un signal d'alarme.
Sécurisez le serveur API : Assurez-vous que le serveur API n'est pas accessible depuis l'Internet ouvert. Utilisez un équilibreur de charge avec une liste blanche d'adresses IP ou un point de terminaison privé.

Phase 2 : Mise en œuvre des contrôles réseau

Network Policy de refus par défaut : Par défaut, tous les pods peuvent communiquer avec tous les pods. Changez cela. Créez une politique de « refus par défaut » pour tout le trafic entrant et sortant, puis autorisez explicitement uniquement les connexions nécessaires au fonctionnement de l'application.
Isolation des Namespace : Utilisez des Namespace pour séparer les environnements (dev, staging, prod) et les différentes équipes. Bien que les Namespace ne soient pas une limite de sécurité stricte, ils facilitent grandement l'application des Network Policies et de RBAC.
Filtrage de la sortie : Ne laissez pas vos pods communiquer avec l'ensemble de l'Internet. Si votre pod n'a besoin de communiquer qu'avec une API de passerelle de paiement spécifique, limitez la sortie à cette plage d'adresses IP ou à ce nom DNS spécifique.

Phase 3 : Sécurité d'exécution et application des politiques

Mettre en œuvre les Pod Security Admissions (PSA) : Utilisez le PSA intégré pour vous assurer qu'aucun pod ne fonctionne en tant que root ou n'utilise le réseau hôte.
Utilisez un outil de sécurité d'exécution : Des outils comme Falco peuvent vous alerter en temps réel si un shell est ouvert à l'intérieur d'un pod ou si un fichier sensible (comme /etc/shadow) est lu.
Système de fichiers racine en lecture seule : Dans la mesure du possible, définissez readOnlyRootFilesystem: true. Cela empêche les attaquants de télécharger des ensembles d'outils (comme nmap ou netcat) dans le conteneur s'ils obtiennent un shell.

Phase 4 : Gestion des identités et des secrets

Arrêtez d'utiliser les secrets K8s pour les données sensibles : Les secrets K8s sont uniquement encodés en base64. Utilisez un gestionnaire de secrets dédié comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault.
Jetons à courte durée de vie : Abandonnez les jetons à longue durée de vie. Utilisez OIDC (OpenID Connect) pour l'authentification des utilisateurs auprès du cluster.
Journalisation d'audit : Activez les journaux d'audit Kubernetes. Si une violation se produit, vous devez savoir exactement qui a appelé quelle API et quand. Sans journaux, vous ne faites que deviner.

Comparaison de différentes approches de sécurité

Il est facile de se perdre dans la jungle des outils de sécurité. Voici une analyse comparative des différentes méthodes et de leur place dans votre stratégie.

Approche	Ce qu'elle fait	Avantages	Inconvénients	Quand l'utiliser
Analyse de vulnérabilités	Recherche de CVE connues dans les images/packages.	Rapide, automatisée, détecte les bogues "connus".	Ne détecte pas les erreurs de configuration et les failles logiques.	À chaque build dans le CI/CD.
Audit de configuration	Vérifie les fichiers YAML par rapport aux benchmarks (comme CIS).	Détecte les erreurs courantes (par exemple, les pods privilégiés).	Peut produire de nombreux "False Positives" ou du bruit.	Avant le déploiement et périodiquement.
Protection d'exécution	Surveille les pods actifs pour détecter les comportements étranges.	Détecte les Zero Day et les attaques actives.	Peut être complexe à régler ; volume d'alertes élevé.	Environnements de production.
Cloud Pentesting	Simule le parcours d'un attaquant humain.	Détecte les kill-chains complexes et les failles logiques.	Prend plus de temps qu'une analyse.	Trimestriellement ou après des changements majeurs.

Le secret est qu'aucune de ces approches n'est "suffisante" à elle seule. Vous avez besoin d'une approche multicouche. Vous analysez les images pour arrêter les bogues connus, vous auditez les configurations pour arrêter les erreurs courantes, vous surveillez l'exécution pour détecter les menaces actives et vous effectuez des Penetration Testing pour trouver les lacunes que les trois autres ont manquées.

Faire évoluer votre sécurité avec les plateformes Cloud-Native

Pour une entreprise de taille moyenne, l'embauche d'un expert en sécurité Kubernetes à temps plein est coûteuse. La plupart des équipes informatiques sont déjà surchargées. C'est là que le modèle "Cloud Pentesting" résout un véritable problème commercial.

Au lieu d'essayer de construire une "red team" interne, vous pouvez utiliser une plateforme comme Penetrify pour combler le fossé. Voici pourquoi c'est important pour K8s en particulier :

1. Pas de frais généraux de matériel La mise en place d'un environnement sûr pour effectuer des Penetration Tests sur un cluster nécessite souvent un miroir de votre environnement de production. Cela représente beaucoup de dépenses dans le cloud. Une plateforme cloud-native vous permet d'exécuter ces évaluations via une architecture gérée, réduisant ainsi la nécessité de créer des "clusters de test" coûteux qui ne servent à rien.

2. Mise à l'échelle à la demande Vos besoins en matière de sécurité évoluent. Peut-être lancez-vous un nouveau microservice pour un client important, ou migrez-vous d'une configuration VM héritée vers EKS. Vous n'avez pas besoin d'un pentester tous les jours, mais vous en avez besoin pendant ces fenêtres à haut risque. Les plateformes cloud vous permettent d'augmenter ou de diminuer la fréquence de vos tests en fonction de votre cycle de publication.

3. Intégration aux flux de travail Le plus gros problème avec les Penetration Testing traditionnels est le "rapport PDF". Vous obtenez un document de 50 pages, il reste dans un e-mail pendant trois semaines, puis un développeur doit créer manuellement des tickets Jira pour chaque constatation. Les plateformes modernes alimentent les résultats directement dans votre SIEM ou vos systèmes de billetterie existants. Lorsqu'une vulnérabilité est détectée dans un cluster K8s, elle doit immédiatement devenir un ticket dans le backlog, et non une puce dans un document.

Scénario réel : L'attaque du "chemin de moindre résistance"

Pour illustrer pourquoi nous nous concentrons sur les "chaînes" de vulnérabilité, retraçons une attaque hypothétique sur un site de commerce électronique basé sur Kubernetes.

La configuration :

Une application React frontend s'exécutant dans un pod.
Un pod API backend.
Un pod de base de données.
Une instance Prometheus pour la surveillance.

La chaîne d'attaque :

L'entrée : L'attaquant trouve une vulnérabilité Server-Side Request Forgery (SSRF) dans l'application frontend. Il s'agit d'un bogue web courant.
La reconnaissance : En utilisant le SSRF, l'attaquant ne peut pas atteindre la base de données, mais il peut atteindre le DNS interne de Kubernetes. Il découvre que le service Prometheus fonctionne sur le port 9090.
Le pivot : Il découvre que l'instance Prometheus a un tableau de bord ouvert sans mot de passe. Dans le tableau de bord, il trouve une étiquette qui révèle les adresses IP internes de tous les autres pods dans l'espace de noms.
L'escalade : Il utilise à nouveau le SSRF, mais cette fois, il cible le serveur API interne en utilisant un jeton divulgué qu'il a trouvé dans un journal Prometheus (qui enregistrait accidentellement les en-têtes).
Les joyaux de la couronne : Le jeton a la permission get secrets. Il extrait le mot de passe root de la base de données et vide toute la table des clients.

Comment arrêter cette chaîne ? Remarquez que la plupart de ces bogues ne sont pas "critiques" en soi. Un SSRF est mauvais, mais si vous avez des Network Policies bloquant l'accès au pod Prometheus, l'attaque s'arrête à l'étape 2. Si Prometheus est authentifié, elle s'arrête à l'étape 3. Si le jeton du compte de service n'est pas monté automatiquement, elle s'arrête à l'étape 4.

C'est ce que le cloud pentesting trouve. Il ne se contente pas de dire "Vous avez un SSRF" ; il dit "Votre SSRF permet à un attaquant de voler votre base de données via Prometheus". C'est le genre d'information qui motive réellement la priorité de la sécurité.

Erreurs courantes que les équipes commettent lors de la sécurisation de K8s

Même avec les meilleures intentions, les gens font des erreurs. Voici les pièges les plus courants.

1. Faire confiance au "Cloud Default"

De nombreuses équipes supposent que, parce qu'elles utilisent GKE ou EKS, le "cluster" est sécurisé. N'oubliez pas : le fournisseur de cloud sécurise l'infrastructure (le matériel, l'hyperviseur, la disponibilité du plan de contrôle), mais c'est vous qui sécurisez la configuration. Si vous déployez un pod en tant que root, AWS ne va pas vous en empêcher.

2. Dépendance excessive aux "Security Groups"

Les security groups (pare-feu) sont parfaits pour bloquer le trafic externe, mais ils sont inutiles pour le trafic interne pod-to-pod. Une fois qu'un paquet est à l'intérieur du cluster, le security group ne le voit pas. Vous devez utiliser les Kubernetes Network Policies pour la segmentation interne.

3. Ignorer la phase de "Build"

Attendre que l'application soit déployée pour la scanner. C'est un cauchemar pour les développeurs. Au moment où vous leur dites "cette image est vulnérable", ils sont déjà passés à la fonctionnalité suivante. Déplacez la sécurité vers la gauche. Placez le scan dans le pipeline CI/CD afin que le développeur reçoive l'erreur pendant qu'il écrit encore le code.

4. Ne pas tester le côté "Humain"

Vous pouvez avoir le cluster le plus sécurisé au monde, mais si votre lead dev stocke le cluster-admin kubeconfig dans un canal Slack public, rien de tout cela n'a d'importance. La sécurité est une culture, pas seulement un ensemble de fichiers YAML.

FAQ : Sécurité Kubernetes et Cloud Penetration Testing

Q : L'analyse automatisée est-elle la même chose qu'un Penetration Test ?

R : Non. L'analyse automatisée est comme un détecteur de fumée : elle vous indique qu'il y a un problème en se basant sur des schémas connus. Un Penetration Test est comme un commissaire aux incendies : un humain (ou une simulation avancée) qui examine la structure du bâtiment, vérifie les sorties et trouve l'endroit où une étincelle pourrait déclencher un incendie. Vous avez besoin des deux.

Q : À quelle fréquence dois-je effectuer un Penetration Test de mes clusters Kubernetes ?

R : Au minimum, une fois par an. Cependant, pour les entreprises ayant des cycles de publication rapides, des tests trimestriels ou des tests "basés sur des événements" (après un changement d'architecture majeur ou le lancement d'une nouvelle fonctionnalité) sont préférables. L'évaluation continue est la référence.

Q : Un Penetration Test peut-il faire planter mon cluster de production ?

R : Cela peut arriver, si c'est mal fait. C'est pourquoi un cloud Penetration Testing professionnel est généralement effectué dans un environnement de staging qui reflète la production. Un bon pentester sait comment tester avec précaution sans faire tomber vos pods.

Q : Qu'est-ce qui est le plus important : RBAC ou Network Policies ?

R : Ni l'un ni l'autre n'est "plus" important ; ils résolvent des problèmes différents. RBAC contrôle qui peut faire quoi (Autorisation). Network Policies contrôle qui peut parler à qui (Communication). Si vous avez un excellent RBAC mais pas de Network Policies, un pod compromis peut toujours renifler le trafic ou attaquer d'autres services.

Q : Est-ce que Penetrify prend en charge les Kubernetes managés comme EKS ou GKE ?

R : Oui. Parce que Penetrify est cloud-native, il est conçu pour s'intégrer aux principaux fournisseurs de cloud. Il se concentre sur les vulnérabilités qui existent, que le cluster soit auto-géré ou managé.

Points clés à retenir : Votre plan de sécurité sur 30 jours

Si vous vous sentez dépassé, n'essayez pas de tout faire en même temps. Décomposez-le en une feuille de route mensuelle.

Semaine 1 : Visibilité et bases de référence

Effectuez un audit de configuration (essayez d'utiliser kube-bench ou polaris).
Listez chaque ClusterRole et voyez qui a accès à cluster-admin.
Activez la journalisation d'audit pour votre plan de contrôle.

Semaine 2 : Réduire la surface d'attaque

Définissez automountServiceAccountToken: false pour tous les pods qui n'ont pas besoin d'accès API.
Mettez en œuvre une politique de réseau "Default Deny" dans votre namespace de développement.
Mettez à jour toutes vos images de base vers les dernières versions stables.

Semaine 3 : Renforcer l'accès

Remplacez tous les conteneurs "privileged: true" par des capacités spécifiques.
Déplacez vos mots de passe sensibles des K8s Secrets vers un gestionnaire de secrets.
Configurez une politique Pod Security Admission pour bloquer les conteneurs root.

Semaine 4 : Validation et tests

C'est là que vous arrêtez de deviner et commencez à savoir. Planifiez un cloud pentest via Penetrify pour voir si les modifications que vous avez apportées au cours des semaines 1 à 3 ont réellement fonctionné.
Utilisez les résultats de ce pentest pour créer un backlog de correctifs de sécurité pour le mois suivant.

Dernières réflexions

Kubernetes est une bête. Il nous donne une puissance incroyable, mais cette puissance s'accompagne de beaucoup de complexité. La plus grande erreur que vous puissiez commettre est de supposer que "complexe" signifie "sécurisé". En réalité, la complexité est souvent l'endroit où se cachent les vulnérabilités.

Sécuriser votre cluster n'est pas un projet ponctuel ; c'est une habitude. Il s'agit de passer d'un état d'esprit de "J'espère que nous sommes en sécurité" à "Je sais que nous sommes en sécurité parce que j'ai essayé de le casser". En combinant un RBAC strict, des politiques de réseau strictes et un cloud Penetration Testing régulier, vous pouvez profiter des avantages de Kubernetes sans passer des nuits blanches à vous demander si un seul fichier YAML mal configuré va faire tomber votre entreprise.

Si vous êtes prêt à arrêter de deviner, il est temps de mettre votre infrastructure à l'épreuve. Que vous soyez une petite équipe ou une grande entreprise, l'objectif est le même : trouver les trous avant que les méchants ne le fassent. Une plateforme comme Penetrify rend ce processus gérable, évolutif et, surtout, exploitable. N'attendez pas une violation pour découvrir où sont vos faiblesses. Prenez de l'avance dès aujourd'hui.

Retour au blog