Lorsque Tesla a découvert en 2018 que des pirates informatiques menaient des opérations de cryptomining au sein de ses clusters Kubernetes, la cause première s'est avérée étonnamment simple : un tableau de bord exposé sans mot de passe. Des années plus tard, ce type de mauvaise configuration continue de nuire à de nombreuses entreprises. Quatre-vingt-dix pour cent des entreprises ont connu au moins un incident de sécurité Kubernetes au cours des 12 derniers mois (Red Hat 2024), et les nouveaux clusters font face à leur première tentative d'attaque dans les 18 minutes suivant leur déploiement (Wiz 2025). Avec une croissance prévue du marché de la sécurité des conteneurs et de Kubernetes, qui passera de 1,7 milliard de dollars en 2024 à 8-9 milliards de dollars d'ici 2030-2033, il n'a jamais été aussi urgent de sécuriser ces environnements. Ce guide couvre tout l'éventail de la sécurité Kubernetes, des modèles fondamentaux et des meilleures pratiques en matière de cycle de vie à la détection comportementale des menaces et aux stratégies cloud qui permettent de faire face aux attaques les plus sophistiquées d'aujourd'hui.
La sécurité Kubernetes désigne l'ensemble des pratiques, outils et politiques qui protègent les charges de travail conteneurisées et leur infrastructure d'orchestration tout au long du cycle de vie des applications, depuis la création d'images jusqu'au déploiement et à l'exécution. Elle englobe le renforcement de la configuration, le contrôle d'accès (RBAC), la segmentation du réseau, la gestion des secrets, la détection des menaces d'exécution et la surveillance de la conformité au niveau du plan de contrôle, des nœuds de travail, des images de conteneurs, du trafic réseau et des couches de configuration.
Pourquoi est-ce important ? Kubernetes n'est pas sécurisé par défaut. Dans sa configuration par défaut, la plateforme privilégie la flexibilité et la rapidité des développeurs plutôt que la sécurité renforcée. Les entreprises doivent configurer activement le contrôle d'accès basé sur les rôles (RBAC), les politiques réseau, le chiffrement des secrets, les normes de sécurité des pods et la journalisation des audits avant qu'un cluster ne soit prêt pour la production. Selon la documentation sur les concepts de sécurité de Kubernetes, le modèle de responsabilité partagée fait peser la charge de la configuration de la sécurité sur l'opérateur.
Les conséquences commerciales d'une erreur dans ce domaine sont graves. Soixante-sept pour cent des entreprises ont retardé ou ralenti leurs déploiements en raison de problèmes de sécurité liés à Kubernetes, 46 % ont subi une perte de revenus ou de clients, et 30 % ont été condamnées à une amende (Red Hat 2024). La surface d'attaque croissante d'un cluster Kubernetes s'étend au serveur API, au magasin de données etcd, au kubelet, au runtime des conteneurs, à la superposition réseau et à toutes les charges de travail qui y sont exécutées.
La sécurité des conteneurs se concentre sur les images individuelles des conteneurs, les environnements d'exécution et les mécanismes d'isolation. La sécurité Kubernetes ajoute des préoccupations au niveau de la couche d'orchestration qui vont au-delà d'un conteneur individuel. Il s'agit notamment des contrôles d'accès au serveur API, des politiques RBAC régissant qui peut faire quoi dans le cluster, des communications inter-pods et inter-espaces de noms régies par des politiques réseau, de la gestion des secrets et du chiffrement au repos, des contrôleurs d'admission qui valident les charges de travail avant le déploiement, et de la configuration à l'échelle du cluster, telle que la journalisation d'audit et les normes de sécurité des pods.
Une image de conteneur renforcée déployée dans un cluster mal configuré reste vulnérable. La sécurité Kubernetes concerne l'infrastructure qui entoure, connecte et orchestre ces conteneurs.
Les erreurs de configuration sont à l'origine de la plupart des violations de Kubernetes, mais les attaques ciblées utilisant des mouvements latéraux et l'escalade des privilèges sont en forte augmentation. Plus de 50 % des personnes interrogées dans le rapport Red Hat 2024 ont cité les erreurs de configuration comme la principale cause des incidents de sécurité Kubernetes. La répartition des principales préoccupations en matière de sécurité est éloquente : vulnérabilités (33 %), erreurs de configuration et expositions (27 %), attaques actives (24 %) et échecs aux audits de conformité (16 %).
Pour aggraver encore la situation, 81 % des clusters EKS s'appuient toujours sur l'authentification CONFIG_MAP obsolète (Wiz 2025), créant ainsi un risque hérité que les pirates exploitent activement. Les attaques par mouvement latéral basées sur des conteneurs ont augmenté de 34 % en 2025 (Tigera), reflétant une transition de l'exploitation opportuniste des erreurs de configuration vers des opérations délibérées après compromission.
Ces études de cas datées et sourcées démontrent les conséquences d'une sécurité Kubernetes inadéquate et les leçons à tirer de chaque incident.
MITRE ATT&CK fournit un langage commun pour mettre en correspondance les menaces Kubernetes avec les contrôles de sécurité. Le tableau suivant met en correspondance les tactiques clés de la matriceMITRE ATT&CK avec des contrôles de sécurité Kubernetes spécifiques.
Tableau 1 : Matrice MITRE ATT&CK mappés aux contrôles de sécurité Kubernetes
Le modèle des 4 C fournit un cadre de défense multicouche où chaque couche de sécurité dépend de l'intégrité de la couche sous-jacente. Ce modèle, largement adopté dans l'industrie, organise la sécurité Kubernetes en quatre couches imbriquées.
Chaque couche s'appuie sur celle qui la précède. Une image de conteneur parfaitement sécurisée n'offre qu'une protection limitée si le cluster sur lequel elle s'exécute autorise l'accès anonyme à l'API. De même, les configurations cloud rigoureuses perdent toute leur valeur si le code exécuté dans les conteneurs contient des secrets codés en dur ou des dépendances vulnérables.
Une sécurité Kubernetes efficace nécessite des contrôles à chaque phase du cycle de vie, la détection à l'exécution comblant les lacunes que l'analyse lors de la compilation ne peut pas traiter. Les pratiques suivantes, organisées selon les phases de compilation, de déploiement et d'exécution, fournissent une liste de contrôle complète pour la sécurité Kubernetes, alignée sur la fiche de sécurité OWASP Kubernetes.
Un contexte de sécurité Kubernetes définit les paramètres de privilèges et de contrôle d'accès pour un pod ou un conteneur. Ces paramètres comprennent l'exécution en tant qu'utilisateur non root, la suppression des capacités Linux, la configuration de systèmes de fichiers root en lecture seule et la définition de profils seccomp. L'application cohérente des contextes de sécurité à toutes les charges de travail empêche de nombreux chemins d'escalade de privilèges courants.
La sécurité d'exécution dans Kubernetes consiste à surveiller et à protéger les charges de travail après leur déploiement. Contrairement à l'analyse lors de la compilation, qui détecte les vulnérabilités connues avant le déploiement, la sécurité d'exécution détecte les menaces actives, les comportements anormaux et zero-day dans les clusters en production. Les organisations ayant mis en place des initiatives DevSecOps avancées (42 % des répondants) complètent la prévention lors de la compilation par la détection lors de l'exécution (Red Hat 2024).
La pile de sécurité basée sur eBPF (Falco, Tetragon, Cilium) est en passe de devenir la norme pour la détection d'exécution Kubernetes avec un impact minimal sur les performances. Les outils suivants représentent les principales options open source dans les catégories analyse, application des politiques et détection d'exécution.
Tableau 2 : Comparaison des outils de sécurité Kubernetes
Kubescape a obtenu le statut « CNCF Incubating » et est utilisé par plus de 25 000 entreprises dans plus de 100 000 cloud (CNCF 2025), ce qui en fait le premier scanner de sécurité Kubernetes accepté par la CNCF.
Le filtre de paquets Berkeley étendu (eBPF) permet une observabilité et une application au niveau du noyau avec moins de 1 % de surcharge CPU (Tetragon), transformant ainsi la manière dont les entreprises abordent la sécurité d'exécution Kubernetes. Les principaux outils basés sur eBPF comprennent :
La pile open source recommandée, composée de Kubescape, Falco, Trivy et Cilium, offre une analyse et une détection complètes de la sécurité Kubernetes avec une surcharge CPU totale de 1 à 2,5 %. Cette efficacité rend la sécurité basée sur eBPF viable pour les charges de travail de production où les budgets de performance sont limités. Pour les organisations qui souhaitent évaluer leurs outils existants, les outils NDR et les systèmes de détection et de prévention des intrusions complètent la détection basée sur eBPF avec une visibilité au niveau du réseau.
La détection comportementale des menaces et la visibilité au niveau du réseau comblent le fossé critique entre les outils de prévention uniquement et les menaces actives qui ciblent les clusters Kubernetes. L'analyse de la configuration et l'application des politiques sont nécessaires, mais insuffisantes. Elles empêchent les configurations malveillantes connues, mais ne peuvent pas détecter les attaquants actifs qui ont contourné les contrôles de prévention.
Kubernetes utilise par défaut un réseau plat où n'importe quel pod peut communiquer avec n'importe quel autre pod. Cela rend la détection des mouvements latéraux essentielle. Les attaquants exploitent cette faille en se déplaçant de pod en pod au sein d'un espace de noms, en passant d'un espace de noms à un autre à travers le cluster et en accédant aux services cloud à partir des pods compromis.
worm TeamPCP worm février 2026) a démontré ce schéma à grande échelle. Un seul point d'ancrage a permis au groupe de répertorier l'ensemble du cluster, d'exécuter des commandes sur toutes les charges de travail et de déployer un DaemonSet privilégié qui a transformé le cluster en un botnet distribué, compromettant au moins 185 serveurs (eSecurity Planet). Avec une augmentation de 34 % des attaques de mouvement latéral basées sur des conteneurs en 2025, la capacité à détecter les modèles de trafic est-ouest anormaux n'est plus facultative.
La détection comportementale des menaces se concentre sur l'identification de modèles anormaux plutôt que sur la correspondance avec des signatures connues. Dans les environnements Kubernetes, ces modèles comprennent les appels API inhabituels, les communications inattendues entre pods, les anomalies d'accès aux identifiants et les indicateurs de détournement de ressources.
La vulnérabilité de télémétrie Kubernetes révélée en janvier 2026 illustre pourquoi cette approche est importante. Les chercheurs ont découvert que l'autorisation GET RBAC des nœuds/proxy, généralement accordée aux outils de surveillance, pouvait être détournée pour exécuter des commandes arbitraires à l'intérieur des pods via l'API Kubelet. Kubernetes a classé cela comme « fonctionnant comme prévu » et ne publiera pas de correctif. La seule défense consiste à détecter les opérations d'exécution anormales à partir des comptes de service de surveillance (The New Stack) — un cas d'utilisation classique pour l'analyse comportementale et la recherche de menaces.
Les méthodes de détection des menaces Kubernetes comprennent :
Aucun guide de sécurité Kubernetes de premier plan n'aborde la question de la détection et réponse aux incidents (NDR) s'intègre à la sécurité Kubernetes — un angle mort important étant donné que la visibilité au niveau du réseau détecte les menaces que les outils basés sur la configuration ne détectent pas du tout.
NDR offre une visibilité sur le trafic est-ouest au sein des clusters Kubernetes, identifiant les modèles de communication anormaux tels que les pods atteignant des services inattendus, les volumes de données inhabituels entre les espaces de noms et les tentatives d'exfiltration de données via des canaux latéraux. Cela complète l'analyse de la configuration et l'application des politiques par une détection active des menaces au niveau du réseau, comblant ainsi le manque de détection qui fait que 90 % des organisations continuent de subir des incidents malgré l'adoption des meilleures pratiques en matière de sécurité Kubernetes.
Le KSPM offre une visibilité continue sur la conformité, et il est désormais essentiel pour les entreprises d'adopter des contrôles Kubernetes adaptés aux cadres réglementaires. La gestion de la sécurité Kubernetes (KSPM) évalue en permanence les configurations des clusters par rapport aux normes de sécurité, identifiant en temps réel les erreurs de configuration, les violations de politiques et les lacunes en matière de conformité.
Les outils KSPM tels que Kubescape, Wiz, Prisma Cloud et Sysdig fournissent une évaluation continue des configurations des clusters Kubernetes par rapport aux références de sécurité, notamment les benchmarks CIS, les normes de sécurité Pod et les politiques organisationnelles personnalisées. Le benchmark CIS Kubernetes, évalué par kube-bench, reste la référence la plus largement adoptée pour le renforcement des clusters. Le Top 10 OWASP Kubernetes fournit un cadre de risques hiérarchisés couvrant la configuration non sécurisée des charges de travail (K01), les vulnérabilités de la chaîne d'approvisionnement (K02), le RBAC trop permissif (K03), les lacunes dans l'application des politiques (K04) et la journalisation inadéquate (K05) via des composants vulnérables (K10). Une version mise à jour est actuellement en cours d'élaboration pour 2025.
Le guide NSA/CISA Kubernetes Hardening Guide v1.2 (août 2022) reste la référence officielle du gouvernement américain en matière de sécurité Kubernetes. Il couvre les risques liés à la chaîne d'approvisionnement, cybercriminels malveillants et individu . L'automatisation de la conformité s'intensifie en 2026, les organisations étant désormais tenues de démontrer leur conformité continue par le biais d'une collecte automatisée de preuves plutôt que par des évaluations manuelles périodiques (Veeam).
Tableau 3 : Contrôles de sécurité Kubernetes associés aux principaux cadres réglementaires
Les exigences en matière de SBOM évoluent depuis que l'OMB M-26-05 est passé à une approche basée sur les risques en janvier 2026. Les fournisseurs Cloud doivent désormais fournir des SBOM des environnements de production d'exécution sur demande, ce qui favorise l'intégration de la génération de SBOM dans les pipelines CI/CD Kubernetes.
La sécurité Kubernetes évolue rapidement grâce à des outils basés sur eBPF, au renforcement des plateformes et au passage de stratégies de défense axées uniquement sur la prévention à des stratégies axées sur la détection. Plusieurs développements en 2025-2026 sont en train de redéfinir la manière dont les organisations abordent l'architecture de sécurité Kubernetes.
Le renforcement de la plateforme s'accélère. Six fonctionnalités de sécurité majeures ont atteint un statut stable dans Kubernetes v1.32-v1.35 en 2025, notamment les améliorations apportées aux jetons Bound ServiceAccount, les conteneurs Sidecar, les montages récursifs en lecture seule, l'autorisation basée sur des sélecteurs, les restrictions de requêtes anonymes et la suppression ordonnée des espaces de noms. Huit autres fonctionnalités devraient voir le jour en 2026, notamment les espaces de noms utilisateur, les certificats Pod pour mTLS et l'autorisation de récupération d'images (CNCF 2025).
Les transitions critiques des infrastructures requièrent une attention particulière. Ingress-NGINX arrivera en fin de vie en mars 2026, et aucune nouvelle version, correction de bogues ou correctif de sécurité ne sera publié après cette date. Le Comité de réponse à la sécurité Kubernetes recommande de migrer vers Gateway API (blog Kubernetes). Les organisations qui continuent d'utiliser les contrôleurs Ingress-NGINX hérités s'exposent à des vulnérabilités non corrigées.
La validation du marché atteint un niveau sans précédent. L'acquisition de Wiz par Google pour 32 milliards de dollars, la plus importante acquisition jamais réalisée dans le domaine de la cybersécurité, valide le marché de la sécurité cloud et indique que les outils et plateformes de sécurité Kubernetes constituent une priorité stratégique pour les plus grands acteurs du secteur (The Register).
L'adoption du DevSecOps s'accélère. Quarante-deux pour cent des organisations déclarent désormais avoir mis en place des initiatives DevSecOps avancées, tandis que 48 % en sont aux premières étapes (Red Hat 2024). Ce passage d'une sécurité rajoutée à des pratiques de sécurité intégrées réduit l'écart entre la vitesse de développement et la couverture de sécurité.
L'approche Vectra AI en matière de sécurité Kubernetes est axée sur la détection comportementale des menaces et Attack Signal Intelligence. Plutôt que de se fier uniquement à l'analyse de la configuration et à l'application des politiques, Vectra AI les modèles de trafic réseau dans cloud hybrides, y compris le trafic est-ouest au sein des clusters Kubernetes, afin de détecter les indicateurs comportementaux d'attaques actives. Cette approche repose sur la philosophie « assume-compromise » (supposer la compromission) : les pirates intelligents finiront par contourner les contrôles de prévention, c'est pourquoi la détection de leur comportement après la compromission (y compris les mouvements latéraux, l'escalade des privilèges et l'exfiltration de données) permet de réduire le risque réel. En fournissant détection et réponse aux incidents complètent les outils basés sur la configuration, les organisations acquièrent la visibilité nécessaire pour identifier les menaces que la prévention seule ne peut arrêter.
La sécurité Kubernetes est l'ensemble des pratiques, outils et politiques qui protègent les charges de travail conteneurisées et leur infrastructure d'orchestration tout au long du cycle de vie des applications, depuis la création d'images jusqu'au déploiement et à l'exécution. Elle englobe le renforcement de la configuration, le contrôle d'accès via RBAC, la segmentation du réseau via des politiques réseau, la gestion des secrets, la détection des menaces d'exécution et la surveillance de la conformité. Contrairement à la sécurité des conteneurs, qui se concentre sur les images et les environnements d'exécution individuels, la sécurité Kubernetes concerne la couche d'orchestration, y compris le serveur API, le magasin de données etcd, les contrôleurs d'admission et les configurations à l'échelle du cluster. Avec 90 % des entreprises ayant connu au moins un incident au cours de l'année écoulée (Red Hat 2024), une sécurité Kubernetes complète est une nécessité commerciale, et non une amélioration facultative.
Non. Dans sa configuration par défaut, Kubernetes privilégie la flexibilité et la rapidité des développeurs au détriment de la sécurité. Dès leur installation, les clusters autorisent les communications illimitées entre pods, ne chiffrent pas les secrets au repos dans etcd, permettent l'accès anonyme à l'API dans certaines configurations et n'appliquent pas les normes de sécurité des pods. Les organisations doivent configurer activement le RBAC avec le principe du moindre privilège, mettre en œuvre des politiques réseau par défaut refusant l'accès, activer le chiffrement etcd, déployer des contrôleurs d'admission et configurer la journalisation d'audit avant qu'un cluster ne soit prêt pour la production. L'urgence est réelle : les clusters AKS font face à leur première tentative d'attaque dans les 18 minutes suivant leur création, et les clusters EKS dans les 28 minutes (Wiz 2025). Cet écart entre la configuration par défaut et le fonctionnement sécurisé explique pourquoi les meilleures pratiques en matière de sécurité Kubernetes sont essentielles dès le premier jour.
Les 4 C sont Cloud, Cluster, Container et Code. Chaque couche s'appuie sur celle qui la précède. Cloud fournit la base grâce à des politiques IAM, des pare-feu réseau et le chiffrement en transit. Les contrôles au niveau du cluster sécurisent la couche d'orchestration avec RBAC, des contrôleurs d'admission, le chiffrement etcd et la journalisation d'audit. La sécurité des conteneurs renforce les charges de travail individuelles grâce à l'analyse des images, au renforcement des images de base, à l'exécution sans root et aux contextes de sécurité. La sécurité du code traite les vulnérabilités au niveau des applications grâce à l'analyse des dépendances, la détection des secrets et la vérification de la chaîne d'approvisionnement. Une faiblesse au niveau d'une couche externe compromet la sécurité de toutes les couches internes, ce qui fait des 4 C un cadre pratique pour identifier et combler les lacunes de l'ensemble de l'architecture de sécurité Kubernetes.
Les principaux outils open source comprennent Falco (CNCF Graduated) pour la détection des menaces en temps réel via la surveillance des appels système basée sur eBPF, Trivy pour l'analyse complète des vulnérabilités des images de conteneurs et des configurations Kubernetes, Kubescape (CNCF Incubating) pour la gestion de la posture de sécurité dans plus de 25 000 entreprises, OPA/Gatekeeper et Kyverno pour le contrôle d'admission et l'application des politiques, kube-bench pour l'évaluation de la conformité CIS Kubernetes Benchmark, et Tetragon/Cilium pour l'observabilité de la sécurité basée sur eBPF avec moins de 1 % de surcharge CPU. Les plateformes d'entreprise de fournisseurs tels que Wiz, Sysdig et Prisma Cloud un support commercial et des fonctionnalités plus étendues. La pile open source recommandée, composée de Kubescape, Falco, Trivy et Cilium, offre une couverture complète, de la compilation à l'exécution, avec une surcharge CPU totale de 1 à 2,5 %.
La gestion de la posture de sécurité Kubernetes (KSPM) fournit une évaluation continue des configurations de cluster par rapport à des références de sécurité telles que les benchmarks CIS Kubernetes, les normes de sécurité Pod et les politiques organisationnelles personnalisées. Les outils KSPM identifient automatiquement et en temps réel les erreurs de configuration, les violations de politiques et les lacunes en matière de conformité dans les clusters, remplaçant ainsi les évaluations manuelles périodiques. Parmi les principaux outils KSPM, on peut citer Kubescape, Wiz, Prisma Cloud et Sysdig. Contrairement à l'analyse ponctuelle, la KSPM offre une visibilité continue sur les dérives de configuration et la conformité aux politiques, ce qui est de plus en plus exigé par les cadres réglementaires tels que HIPAA, PCI DSS, SOC 2 et NIST 800-53. Avec l'intensification de l'automatisation de la conformité en 2026, la KSPM est devenue une infrastructure essentielle pour les déploiements Kubernetes en entreprise.
Kubernetes fournit des politiques réseau qui contrôlent le flux de trafic entre les pods aux couches 3 et 4 (adresses IP et ports). Par défaut, toutes les communications entre pods sont autorisées sans restriction, créant ainsi un réseau plat qui facilite les mouvements latéraux pour les pirates. Les organisations doivent mettre en œuvre des politiques réseau par défaut refusant le trafic entrant et sortant, n'autorisant explicitement que les chemins de communication nécessaires. Pour un contrôle plus granulaire, Cilium fournit une application de politique réseau basée sur eBPF au niveau de la couche 7 (niveau du protocole d'application), tandis que les solutions de maillage de services telles qu'Istio ou Linkerd ajoutent le TLS mutuel (mTLS) pour les communications cryptées entre pods. Au-delà de l'application des politiques, le NDR offre une visibilité sur les modèles de trafic est-ouest afin de détecter les communications anormales que les violations de politiques ne permettent pas à elles seules de détecter.
Le Top 10 OWASP Kubernetes est une liste hiérarchisée des risques de sécurité les plus critiques dans les environnements Kubernetes, fournissant un cadre commun pour l'évaluation des risques et la cartographie des contrôles. Les risques actuels comprennent la configuration non sécurisée des charges de travail (K01), les vulnérabilités de la chaîne d'approvisionnement (K02), un RBAC trop permissif (K03), l'absence d'application centralisée des politiques (K04), la journalisation et la surveillance inadéquates (K05), l'authentification défaillante (K06), l'absence de segmentation du réseau (K07), les défaillances dans la gestion des secrets (K08), les composants de cluster mal configurés (K09) et les composants Kubernetes obsolètes et vulnérables (K10). Chaque risque est associé à des contrôles spécifiques que les organisations peuvent mettre en œuvre. Une mise à jour pour 2025 est actuellement en cours dans le cadre d'une enquête communautaire. Associé au CIS Kubernetes Benchmark et au NSA/CISA Kubernetes Hardening Guide, le Top 10 de l'OWASP fournit un cadre complet de gestion des risques pour la conformité de la sécurité Kubernetes.