Un cluster Kubernetes mal configuré ne tombe pas d’un coup. Il se compromet par étapes : un pod applicatif vulnérable, un compte de service trop permissif, l’absence de cloisonnement réseau, et l’attaquant se retrouve maître du cluster. Sur 14 audits de clusters de production menés en France, le schéma est presque toujours le même. La bonne nouvelle : la méthode pour le casser est reproductible. La voici en 7 étapes, avec les outils, les prix vrais et les erreurs qui reviennent le plus.
Étape 1 — Cartographier le cluster et le modèle de menace (1-2 jours)
Avant tout scan, on cartographie : nombre de clusters et de namespaces, cloud managé ou self-managed, exposition (API server public ou privé), workloads sensibles, et qui a accès à quoi. On définit le modèle de menace : attaquant externe via une appli exposée, attaquant interne (compte développeur), ou compromission de la supply chain. Sans ce cadrage, on audite dans le vide.
Étape 2 — Auditer le RBAC et les comptes de service (2-3 jours)
Le RBAC est la première cause de compromission totale. On recherche les rôles trop larges (cluster-admin distribué sans raison), les bindings sur des groupes entiers, les comptes de service avec des droits d’écriture sur les secrets ou de création de pods privilégiés. Outils : rbac-tool, kubectl auth can-i en masse, et une revue manuelle des rôles sensibles. Règle : un compte de service applicatif ne doit avoir que les permissions strictement nécessaires.
Notre avis d’expert
« Sur 14 clusters, 11 avaient au moins un compte de service applicatif capable de lire tous les secrets du namespace, et 6 pouvaient créer des pods privilégiés. C’est le chemin n°1 vers le contrôle du cluster : une faille dans l’appli, et l’attaquant hérite de ces droits. Réduire le RBAC au moindre privilège est l’action la plus rentable d’un audit K8s. »
— Tom Petersen, WebGuard Agency
Étape 3 — Vérifier les network policies et l’isolation (1-2 jours)
Par défaut, dans Kubernetes, tout pod peut parler à tout pod. Sans network policies, un pod compromis peut scanner et atteindre l’ensemble des services, y compris les bases de données. On vérifie l’existence de politiques par défaut « deny all » puis d’autorisations explicites, l’isolation des namespaces sensibles, et le filtrage des flux sortants (egress) vers Internet. Outils : kubescape, revue des NetworkPolicy, et tests de connectivité réels entre pods.
Étape 4 — Sécuriser les secrets et la configuration (1 jour)
On chasse les secrets en clair : dans les ConfigMaps, les variables d’environnement, les manifestes versionnés dans Git. On vérifie le chiffrement des secrets au repos (etcd encryption), l’usage d’un gestionnaire externe (Vault, secrets manager cloud, External Secrets Operator), et la rotation. Un secret en clair, c’est une clé d’accès offerte à quiconque lit un namespace.
Audit de cluster Kubernetes — cadrage 30 minutes
Vous voulez savoir si une faille applicative resterait contenue sur votre cluster ou compromettrait tout l’environnement ? WebGuard livre un diagnostic de cadrage en 30 minutes et un plan d’audit chiffré sous 5 jours ouvrés.
Lancez-vous — cadrage 30 min →Étape 5 — Durcir les images et la supply chain (1-2 jours)
On analyse les images de conteneurs : vulnérabilités connues (Trivy), images de base obsolètes, conteneurs qui tournent en root sans securityContext, absence de readOnlyRootFilesystem. Côté supply chain : provenance et signature des images (cosign/sigstore), registres privés, et politiques d’admission (Kyverno ou OPA Gatekeeper) qui refusent les images non signées ou privilégiées. C’est le maillon que les attaques récentes de chaîne d’approvisionnement visent en priorité — voir la perspective développeur de D-Open sur l’audit des dépendances.
Étape 6 — Mettre en place la détection runtime (1-2 jours)
Un audit statique ne suffit pas : il faut détecter les comportements anormaux en temps réel. On déploie Falco (ou un équivalent) pour repérer les exécutions de shell dans un conteneur, les accès suspects au système de fichiers, les connexions sortantes inattendues, et les tentatives d’escalade. On connecte les alertes à un canal de supervision avec une rotation d’astreinte. Sans détection runtime, une compromission peut durer des semaines.
Étape 7 — Documenter la conformité et planifier le re-test (1-2 jours)
On produit un rapport priorisé (findings critiques, élevés, moyens), un mapping vers les benchmarks CIS Kubernetes (kube-bench), et un plan de remediation chiffré. Pour les entités soumises à NIS2, on relie les findings aux exigences applicables — voir notre audit de périmètre NIS2. On planifie un re-test J+30 sur les findings critiques et élevés.
| Étape | Durée | Outils | Risque couvert |
|---|---|---|---|
| 1. Cartographie | 1-2 j | kubectl, doc | Périmètre flou |
| 2. RBAC | 2-3 j | rbac-tool | Compromission totale |
| 3. Network policies | 1-2 j | kubescape | Rebond latéral |
| 4. Secrets | 1 j | Trivy, Vault | Vol de clés |
| 5. Images / supply chain | 1-2 j | Trivy, cosign, Kyverno | Image piégée |
| 6. Runtime | 1-2 j | Falco | Compromission durable |
| 7. Conformité + re-test | 1-2 j | kube-bench | Non-conformité |
Les 3 erreurs qui reviennent le plus (et coûtent le plus)
Un, RBAC trop large : cluster-admin distribué « pour aller plus vite ». Deux, aucune network policy : le cluster est un réseau plat où un pod compromis voit tout. Trois, secrets en clair dans les ConfigMaps ou Git. Chacune transforme une simple faille applicative en compromission de tout le cluster. Pour la gouvernance des charges IA hébergées sur K8s (endpoints d’inférence, flux de données), l’équipe Plug-Tech documente des bonnes pratiques utiles à recouper.
Conclusion : viser l’incident contenu, pas le cluster parfait
Aucun cluster n’est invulnérable, et ce n’est pas l’objectif. L’objectif d’un audit Kubernetes est qu’une faille applicative reste un incident contenu et non une compromission totale. RBAC au moindre privilège, network policies « deny by default », secrets gérés, supply chain maîtrisée et détection runtime : ces cinq leviers font 90 % de la résilience. La méthode 7 étapes ci-dessus est reproductible, pour un budget médian de 24 KEUR HT. Lancez votre cadrage en 30 minutes — vous repartez avec un plan d’audit chiffré, utilisable même si vous ne nous choisissez pas.