Kubernetes ne résout pas vos problèmes de sécurité des applications—il ajoute une couche d'orchestration par-dessus. Chaque cluster introduit un plan de contrôle, un runtime de nœud, un modèle d'identité, un réseau défini par logiciel et un magasin de secrets, chacun avec ses propres modes de défaillance. Un seul RoleBinding trop permissif ou un pod privileged: true peut transformer une vulnérabilité web de faible gravité en une prise de contrôle complète du cluster, et de là en une compromission du compte cloud sous-jacent.
Ce guide explique comment tester concrètement un environnement Kubernetes : la surface d'attaque, les mauvaises configurations qui apparaissent dans presque chaque audit, les vecteurs d'évasion de conteneur qui transforment un pod compromis en accès root sur le nœud, et comment les trois disciplines—l'analyse d'images, les tests d'exécution (runtime testing) et le Penetration Testing de cluster—s'articulent.
La surface d'attaque de Kubernetes
Avant de tester, cartographiez ce qu'un attaquant voit. Un cluster Kubernetes expose quatre composants de grande valeur, et chacun est une cible distincte avec des modes de défaillance distincts.
Le serveur API
Le kube-apiserver est la porte d'entrée de tout. Chaque commande kubectl, chaque contrôleur, chaque charge de travail qui communique avec le cluster passe par lui. Tester le serveur API signifie vérifier que l'accès anonyme est désactivé, que l'authentification est appliquée (pas seulement l'autorisation RBAC derrière une porte ouverte), que les drapeaux --anonymous-auth=false et d'audit-logging sont définis, et que le point d'accès n'est pas inutilement exposé à l'internet public. Un nombre surprenant de clusters gérés et auto-hébergés laissent encore le serveur API accessible de n'importe où avec seulement une protection basée sur des jetons.
Le kubelet
Chaque nœud exécute un kubelet, qui expose une API (port par défaut 10250) pour gérer les pods sur ce nœud. Si le kubelet autorise un accès non authentifié ou en lecture seule (le port hérité 10255), un attaquant qui atteint un nœud—ou un pod qui peut y acheminer du trafic—peut énumérer les pods en cours d'exécution, lire leur environnement et, dans les clusters mal configurés, exécuter des commandes à l'intérieur des conteneurs. Le kubelet est le point de pivot classique que kube-hunter recherche.
etcd
etcd est la base de données du cluster. Il stocke chaque objet, y compris les Secrets, en texte clair à moins que le chiffrement au repos ne soit explicitement activé. L'accès direct à etcd équivaut à un accès cluster-admin : vous pouvez lire toutes les informations d'identification et réécrire l'état du cluster. Les tests vérifient qu'etcd n'est accessible que depuis le plan de contrôle, qu'il nécessite un TLS mutuel et que --encryption-provider-config est configuré afin que les Secrets ne soient pas en texte clair.
RBAC et identité
Le contrôle d'accès basé sur les rôles (RBAC) est le tissu conjonctif. Il décide quels sujets peuvent accéder à quelles ressources. Parce que le RBAC est additif et facile à sur-accorder, il est la source la plus courante de chemins d'escalade de privilèges dans les clusters réels—ce qui est abordé en détail ci-dessous.
Mauvaises configurations courantes de cluster
L'expression mauvaise configuration de sécurité de cluster Kubernetes couvre un ensemble prévisible de schémas. Ce sont les découvertes qui apparaissent dans presque chaque première évaluation, classées approximativement par la fréquence à laquelle elles mènent à une compromission réelle.
Pods privilégiés et sur-capables
Un pod avec securityContext.privileged: true a un accès effectivement illimité à l'hôte. Même sans privilège complet, des capacités dangereuses comme CAP_SYS_ADMIN, allowPrivilegeEscalation: true, ou l'exécution en tant qu'UID 0 donnent à un attaquant bien plus que ce dont la charge de travail a besoin. La solution est un contexte de sécurité restrictif appliqué partout :
Montages hostPath et espaces de noms partagés
Un volume hostPath monte un répertoire du nœud dans le pod. Montez /, /var/run/docker.sock ou /etc/kubernetes et le conteneur peut lire ou écrire le système de fichiers de l'hôte—une évasion immédiate. Il en va de même pour hostPID, hostNetwork et hostIPC, qui rompent la limite d'isolation entre le pod et le nœud. Les tests signalent toute charge de travail demandant ces éléments, à moins qu'il n'y ait une raison documentée et auditée (un CNI ou un DaemonSet de surveillance, par exemple).
Jetons de compte de service par défaut
Par défaut, chaque pod reçoit le jeton de compte de service default de l'espace de noms, monté à l'emplacement /var/run/secrets/kubernetes.io/serviceaccount/token. Si ce compte de service dispose de permissions RBAC significatives—ou si la charge de travail n'a pas besoin d'accès à l'API du tout—le jeton constitue un matériel d'identification gratuit pour quiconque compromet le pod. Définissez automountServiceAccountToken: false sur les charges de travail qui n'appellent pas l'API, et délimitez celles qui le font.
NetworkPolicies manquantes
Par défaut, le réseau Kubernetes est plat : tout pod peut atteindre n'importe quel autre pod dans n'importe quel espace de noms. Sans NetworkPolicies, un seul pod frontal compromis peut communiquer directement avec votre base de données, vos services d'administration internes et le point de terminaison des métadonnées du cloud. Une politique de refus par défaut par espace de noms, avec des règles d'autorisation explicites, constitue la base :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Secrets non chiffrés et métadonnées exposées
Les Secrets Kubernetes sont encodés en base64, non chiffrés. Sans chiffrement etcd au repos, ils sont lisibles par quiconque ayant accès à etcd ou aux sauvegardes. De plus, les pods qui peuvent atteindre le service de métadonnées de l'instance cloud (169.254.169.254) peuvent souvent voler les identifiants de rôle IAM du nœud—le pont entre la compromission du cluster et la compromission du compte cloud.
RBAC : Qui peut faire quoi
Le RBAC Kubernetes contrôle l'accès aux ressources du cluster via les Roles, ClusterRoles, RoleBindings et ClusterRoleBindings. Un bon test va au-delà de la question « quelque chose est-il lié à cluster-admin » et recherche les chemins d'escalade—des chaînes de permissions d'apparence raisonnable qui, combinées, mènent à un contrôle total.
Les verbes à surveiller sont escalate, bind et impersonate. Un sujet qui peut create des pods peut souvent monter un compte de service privilégié et lire son jeton. Un sujet qui peut bind des rôles peut s'octroyer le rôle cluster-admin. Un sujet avec impersonate peut agir en tant que n'importe quel utilisateur. D'autres chemins classiques incluent la capacité de lire les Secrets à l'échelle du cluster, de créer ou modifier des ValidatingWebhookConfigurations (interceptant chaque requête API), ou d'exécuter des commandes dans des pods fonctionnant avec des privilèges plus élevés.
Les tests RBAC pratiques répondent à la question : un compte de service par défaut possède-t-il des permissions dont il n'a pas besoin ? Un sujet limité à un espace de noms peut-il atteindre des ressources à l'échelle du cluster ? Existe-t-il des règles génériques (resources: ["*"], verbs: ["*"]) ? Des outils comme rbac-tool et kubectl-who-can aident à les énumérer, mais l'interprétation de la réelle exploitabilité d'une chaîne est l'endroit où les tests adversariaux prouvent leur valeur.
Tests d'évasion de conteneur
La classe de vulnérabilité la plus critique dans Kubernetes est la vulnérabilité d'évasion de conteneur—permettant de s'échapper d'un conteneur pour accéder au nœud hôte, puis d'utiliser ce point d'ancrage pour un mouvement latéral. C'est le cœur du problème de sécurité Docker lié aux vulnérabilités d'évasion de conteneur, et cela s'applique que votre runtime soit containerd, CRI-O ou Docker.
Les vecteurs d'évasion se répartissent en deux catégories. La première est liée à la configuration : le conteneur a reçu suffisamment d'accès pour s'échapper. Un fichier /var/run/docker.sock inscriptible permet à un conteneur de créer un nouveau conteneur privilégié sur l'hôte. Un pod privilégié peut monter le système de fichiers racine de l'hôte et écrire une clé SSH ou une tâche cron. hostPID expose les processus de l'hôte à l'injection. Ce sont les évasions courantes, à forte probabilité, et elles correspondent directement aux erreurs de configuration mentionnées ci-dessus.
La deuxième catégorie est basée sur l'exploitation : les CVEs du noyau et du runtime. Des exemples historiques comme CVE-2019-5736 (écrasement de /proc/self/exe de runc) et diverses failles de cgroups et du noyau permettent à un attaquant de s'échapper même d'un conteneur raisonnablement configuré. Les tests ici consistent à connaître les versions de runtime et de noyau que vous utilisez, à les vérifier par rapport aux CVEs d'évasion connues, et à confirmer que les contrôles de défense en profondeur (seccomp, AppArmor/SELinux, gVisor ou Kata pour les charges de travail à haut risque) sont réellement appliqués plutôt que définis sur Unconfined.
Une chaîne d'attaque réaliste : une faille SSRF dans une charge de travail web atteint le point d'accès des métadonnées du cloud → vole le rôle IAM du nœud → le rôle peut extraire des images d'un registre de conteneurs et le compte de service du pod peut lister les Secrets → un Secret contient un kubeconfig d'administrateur de cluster → l'attaquant planifie un pod privilégié sur chaque nœud. Chaque étape est banale. Enchaînées, c'est la fin de partie. C'est précisément le genre de cheminement en plusieurs étapes que les scanners automatisés à problème unique manquent.
Analyse de sécurité des conteneurs vs Tests de runtime vs Pentesting de cluster
Les équipes demandent souvent quel outil "assure la sécurité de Kubernetes". La réponse honnête est qu'il existe trois disciplines différentes, qu'elles répondent à des questions différentes, et qu'un programme mature les exécute toutes les trois. Comprendre l'analyse de sécurité des conteneurs vs les tests de runtime—et où se situe le pentesting de cluster—est la clé pour ne pas gaspiller de budget sur une couverture redondante tout en laissant de réelles lacunes.
| Dimension | Analyse d'images | Tests d'exécution | Penetration Testing de cluster |
|---|---|---|---|
| Question à laquelle il répond | Cette image contient-elle des paquets connus pour être vulnérables ? | La charge de travail en cours d'exécution se comporte-t-elle de manière sûre actuellement ? | Un attaquant peut-il réellement compromettre le cluster ? |
| Quand il s'exécute | Build / registre / porte CI | En continu, dans le cluster en direct | Ponctuel, adversarial |
| Ce qu'il inspecte | Couches d'image, paquets OS, bibliothèques, Dockerfile | Appels système, comportement des processus, flux réseau, dérive | RBAC, chemins d'évasion, mouvement latéral, exploits de charge de travail |
| Détecte | CVEs, dépendances obsolètes, secrets dans les couches | Anomalies, crypto-mineurs, egress inattendu | Chemins d'attaque chaînés et exploitables de bout en bout |
| Manque | Configuration d'exécution, RBAC, failles logiques | Mauvaises configurations latentes non encore déclenchées | Problèmes en dehors de la fenêtre de test |
| Exemples d'outils | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, Penetration Test manuel, Penetrify |
| Adaptation à l'automatisation | Entièrement automatisable en CI | Agent toujours actif | Planifié + continu basé sur l'IA |
L'analyse d'images est peu coûteuse, rapide et a sa place dans chaque pipeline—mais une image parfaitement analysée s'exécute toujours en tant que root avec un montage hostPath si vous le permettez. Les tests d'exécution détectent ce qui se passe mais vous en disent peu sur ce qui pourrait se produire. Le Penetration Testing de cluster est le seul des trois qui prouve l'exploitabilité en enchaînant les découvertes comme le ferait un attaquant. Aucun ne remplace les autres.
Outillage : kube-bench, kube-hunter et Trivy
Un flux de travail robuste d'analyse de sécurité des conteneurs pour Kubernetes combine généralement trois outils open-source essentiels, chacun avec un rôle clair. Ils sont complémentaires, pas concurrents.
kube-bench
kube-bench exécute le CIS Kubernetes Benchmark sur vos nœuds et votre plan de contrôle. C'est un auditeur de configuration : il vérifie les drapeaux du serveur API, les paramètres kubelet, les permissions de fichiers sur les composants du cluster et la configuration etcd par rapport à une norme de durcissement bien connue. Exécutez-le sur chaque nœud et en CI contre vos manifestes de cluster. Il vous indique si votre cluster est construit selon les spécifications ; il ne vous dit pas si les spécifications sont attaquées.
kube-hunter
kube-hunter est un outil de reconnaissance active. Dirigé vers un cluster (ou exécuté comme un pod à l'intérieur), il sonde les kubelets exposés, les points d'extrémité API accessibles, le service de métadonnées et les points faibles connus, puis rapporte ce qu'un attaquant pourrait découvrir. Il est plus proche d'un scanner réseau pour Kubernetes qu'un Penetration Test complet—excellent pour la cartographie de surface, limité pour prouver l'exploitation de bout en bout.
Trivy
Trivy est le scanner couteau suisse : CVEs d'images conteneur, analyse des mauvaises configurations de manifestes IaC et Kubernetes, secrets exposés et génération de SBOM. C'est le choix naturel pour la colonne "Analyse d'images" ci-dessus et il s'intègre proprement dans les pipelines de build. Associez-le à kube-bench pour la couverture de la configuration et à kube-hunter pour la reconnaissance en direct, et vous obtenez une base open-source solide.
Ce que ce trio ne fait pas, c'est raisonner sur la logique de votre application, enchaîner une vulnérabilité de la couche web pour prendre le contrôle d'un cluster, ou adapter son approche comme le ferait un attaquant humain. C'est cette lacune que la section suivante aborde. Pour intégrer ces scanners dans votre pipeline de livraison, consultez notre guide sur le CI/CD Penetration Testing et l'automatisation de la sécurité des pipelines.
La couche web et API des charges de travail
Voici la partie que la plupart des programmes de sécurité Kubernetes sous-estiment : les charges de travail elles-mêmes. Votre cluster héberge des applications web et des API, et c'est de là que provient généralement le point d'entrée initial. Un attaquant commence rarement par un kubeconfig volé—il commence par une SSRF, un contournement d'authentification, ou une vulnérabilité d'injection dans un service que vous avez déployé, et ensuite pivote vers le cluster en utilisant les mauvaises configurations mentionnées ci-dessus.
C'est exactement là que le Penetration Testing autonome basé sur l'IA s'intègre. Les scanners de configuration et les benchmarks CIS ne peuvent pas trouver un contournement d'authentification de logique métier dans votre service de paiement ; ils n'ont jamais été conçus pour cela. Les tests basés sur l'IA exercent les points d'extrémité web et API en cours d'exécution au sein de vos charges de travail comme le ferait un attaquant—sondant l'authentification, l'autorisation, l'injection et la SSRF—puis suivent la chaîne : d'une vulnérabilité de charge de travail, au jeton de compte de service monté, aux permissions du cluster que ce jeton déverrouille, jusqu'au rôle IAM cloud derrière le nœud.
Cette couverture continue de la couche applicative, enchaînant les exploits, complète—plutôt que de remplacer—votre pipeline kube-bench et Trivy. Pour la dimension spécifique aux API, notre analyse approfondie sur l'automatisation des tests de sécurité des API couvre l'OWASP API Top 10 et la manière de rendre ces tests reproductibles sur l'ensemble des déploiements.
Si vous êtes encore en train de définir les charges de travail et les clusters à prioriser, l'article complémentaire sur les tests de sécurité des conteneurs pour les images Docker et la protection runtime couvre plus en détail les aspects liés aux images et au runtime, et notre guide sur la correction des mauvaises configurations courantes des clusters Kubernetes fournit des étapes de remédiation concrètes pour les problèmes mentionnés ci-dessus.
Tester Kubernetes avec Penetrify
Les tests de sécurité Kubernetes de Penetrify couvrent le RBAC, la sécurité des pods, les politiques réseau, la gestion des secrets, les vecteurs d'évasion de conteneurs et les configurations Kubernetes gérées (EKS, AKS, GKE). Les tests évaluent à la fois la couche Kubernetes et la couche d'intégration du fournisseur de cloud—car un compromis Kubernetes conduit souvent à un compromis du compte cloud via les comptes de service liés et les rôles IAM.
La différence de coût est la raison pour laquelle les équipes l'automatisent. Un Penetration Test Kubernetes manuel traditionnel effectué par un cabinet de conseil coûte généralement entre 5 000 $ et 50 000 $ par mission et vous fournit un instantané ponctuel qui est obsolète dès que vous déployez votre prochaine version. Penetrify fonctionne en continu à partir de 100 $ à 5 000 $ par mois, re-testant chaque fois que votre cluster change. Pour une analyse plus complète de ce qui motive ces chiffres, consultez notre comparaison des coûts de Penetration Testing.
Ce qu'il faut retenir
Kubernetes ajoute une couche d'orchestration entière de surface d'attaque en plus de votre infrastructure cloud. Le tester nécessite trois disciplines complémentaires—l'analyse d'images, la surveillance d'exécution et le cluster Penetration Testing—ainsi que des tests adversariaux des charges de travail web et API qui offrent aux attaquants leur première prise. Les scanners de configuration renforcent la construction ; seul le Penetration Testing par enchaînement d'exploits prouve ce qu'un attaquant peut réellement atteindre.
Penetrify combine le Penetration Testing autonome par IA de vos charges de travail avec des tests d'intégration de cluster et de cloud, en continu et à partir de 100 $/mois—afin que la sécurité de votre Kubernetes suive le rythme de chaque déploiement au lieu de chaque audit annuel.