Container Escape 2026 : Docker, containerd et Kubernetes

En 2026, les container escapes représentent l'une des menaces les plus redoutées dans les environnements DevSecOps modernes. Comprendre comment un attaquant peut s'évader d'un conteneur Docker, exploiter containerd ou compromettre un cluster Kubernetes est devenu indispensable pour tout professionnel de la cybersécurité. Les techniques évoluent constamment : abus des capabilities Linux, exploitation de runc via des CVE critiques, montage de répertoires sensibles du nœud hôte, ou encore détournement du socket Docker exposé par négligence de configuration. Cet article présente un panorama exhaustif et actualisé des vecteurs d'évasion de conteneurs en 2026, des nouvelles CVE affectant l'écosystème cloud-native, des méthodes de détection avancées et des contre-mesures concrètes permettant de réduire drastiquement la surface d'attaque de vos déploiements. Que vous soyez RSSI, ingénieur DevSecOps, testeur d'intrusion ou architecte cloud, cette ressource vous apporte les connaissances techniques nécessaires pour défendre vos infrastructures conteneurisées contre les attaques les plus sophistiquées de 2026.

Comprendre les container escapes en 2026

Un container escape désigne l'ensemble des techniques permettant à un processus s'exécutant à l'intérieur d'un conteneur de sortir de son isolation et d'accéder aux ressources de l'hôte sous-jacent ou d'autres conteneurs du même cluster. En 2026, cette classe d'attaques évolue rapidement sous l'effet conjugué de la multiplication des déploiements Kubernetes en production et de l'accélération du rythme de publication des CVE critiques affectant l'écosystème containerd et runc.

Les conteneurs reposent sur deux primitives d'isolation du noyau Linux : les namespaces (cloisonnement PID, network, mount, UTS, IPC, user) et les cgroups (limitation et comptabilisation des ressources). Contrairement à la virtualisation matérielle basée sur un hyperviseur de type 1 ou 2, les conteneurs partagent le noyau Linux de l'hôte. Cette architecture offre des performances supérieures mais introduit une surface d'attaque significative : toute vulnérabilité noyau ou faiblesse dans le runtime de conteneur peut potentiellement traverser les frontières d'isolation et compromettre l'hôte entier.

Selon le framework MITRE ATT&CK, la technique T1610 - Deploy Container et les sous-techniques associées couvrent les abus liés aux environnements conteneurisés. Les adversaires exploitent les container escapes dans les phases de Privilege Escalation et de Defense Evasion pour pivoter de la workload compromise vers l'infrastructure sous-jacente, puis vers le cluster Kubernetes dans son ensemble.

En 2026, le nombre moyen de jours entre la divulgation d'une CVE critique affectant runc ou containerd et son exploitation active en production est descendu sous les 10 jours selon les rapports des CERT. Cette fenêtre d'exploitation réduite impose aux équipes SecOps une vigilance accrue sur le cycle de vie des patches de leurs runtimes de conteneurs.

Les principaux vecteurs d'attaque container escape en 2026

En 2026, les chercheurs en sécurité offensive identifient six grandes familles de vecteurs d'évasion de conteneurs. Chacune présente un niveau de complexité et de pré-requis différent, mais toutes peuvent conduire à une compromission totale du nœud hôte et, par extension, du cluster Kubernetes entier.

• Exploitation du socket Docker exposé : Le montage de /var/run/docker.sock à l'intérieur d'un conteneur est l'erreur de configuration la plus répandue en 2026. Un attaquant avec accès à ce socket peut créer un nouveau conteneur privilégié montant le système de fichiers hôte et obtenir un shell root en quelques commandes.
• CVE sur runc et containerd : runc, le runtime de bas niveau utilisé par Docker et containerd, a été affecté par plusieurs CVE critiques au fil des années. En 2026, la CVE-2024-21626 reste exploitable sur les environnements non patchés, et de nouvelles vulnérabilités dans la chaîne OCI continuent d'émerger.
• Capabilities Linux excessives : Des capabilities comme CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_NET_ADMIN, CAP_DAC_OVERRIDE ou CAP_DAC_READ_SEARCH accordées sans discernement permettent de nombreuses techniques d'évasion bien documentées.
• Montages hostPath dangereux : Sur Kubernetes, un volume hostPath pointant vers /, /etc, /proc, /sys ou /var/lib/kubelet offre un accès direct aux ressources de l'hôte, y compris les credentials d'accès au cluster.
• Conteneurs privileged : Un conteneur lancé avec le flag --privileged dispose de toutes les capabilities Linux et peut monter n'importe quel device de l'hôte, rendant la sortie du conteneur triviale.
• Exploitation du noyau Linux : Les vulnérabilités noyau comme DirtyPipe (CVE-2022-0847) et OverlayFS (CVE-2023-0386) permettent l'escalade de privilèges depuis l'intérieur d'un conteneur non privilégié sans aucune capability spéciale.

CVE critiques Docker, containerd et runc en 2026

L'année 2026 s'inscrit dans une tendance préoccupante : la surface d'attaque de l'écosystème OCI (Open Container Initiative) s'élargit à mesure que de nouvelles fonctionnalités sont ajoutées à containerd, runc, BuildKit et CRI-O. La veille sur les CVE affectant ces composants est désormais une obligation opérationnelle pour toute équipe gérant des workloads conteneurisées en production.

La CVE-2024-21626 mérite une attention particulière. Cette vulnérabilité dans runc exploite un file descriptor leak via le répertoire de travail (WORKDIR) d'une image Docker malveillante. En ciblant le pseudo-fichier /proc/self/fd/, un attaquant peut obtenir un accès en écriture sur le système de fichiers de l'hôte. La particularité redoutable de cette technique réside dans le fait qu'elle ne nécessite aucune capability spéciale et fonctionne sur des conteneurs non-privilégiés — ce qui en fait un vecteur idéal pour les attaques par supply chain via des images Docker compromises.

Les quatre CVE de la série Leaky Vessels (CVE-2024-21626, CVE-2024-23651, CVE-2024-23652, CVE-2024-23653), divulguées en janvier 2024 par Snyk, ont mis en lumière la complexité croissante de la chaîne d'outils de build des conteneurs. En 2026, les organisations qui n'ont pas appliqué les correctifs correspondants restent exposées à des attaques sophistiquées pouvant cibler leurs pipelines CI/CD.

Techniques d'évasion depuis Docker en 2026

La première catégorie d'exploitation cible Docker Engine directement. L'abus du socket Docker (/var/run/docker.sock) reste la technique la plus accessible et la plus fréquemment observée en 2026. Si un attaquant compromet un conteneur où ce socket est monté — pratique encore répandue dans les pipelines CI/CD utilisant Docker-in-Docker — il peut exécuter des commandes Docker arbitraires avec les privilèges du daemon Docker, qui s'exécute en root sur l'hôte.

La technique du privileged container breakout via montage de device est classique mais toujours redoutablement efficace en 2026. Un conteneur lancé avec docker run --privileged dispose d'un accès complet aux devices du système hôte via /dev/. En montant le disque racine de l'hôte (mount /dev/sda1 /mnt), l'attaquant peut modifier des fichiers système critiques : ajout d'une entrée crontab, modification de /root/.ssh/authorized_keys, ou injection d'une bibliothèque malveillante via /etc/ld.so.preload.

En 2026, les techniques basées sur cgroup v1 release_agent restent pertinentes sur les environnements encore configurés avec cgroup v1. Cette méthode exploite la possibilité de configurer un script exécuté sur l'hôte lorsqu'un cgroup devient vide. Sur les systèmes utilisant cgroup v1 sans les protections adéquates, cette technique fonctionne depuis un conteneur avec CAP_SYS_ADMIN et peut conduire à une exécution de commandes root sur l'hôte en moins de 30 secondes. La migration vers cgroup v2, par défaut dans les noyaux Linux récents, atténue significativement ce risque.

L'injection via CAP_SYS_PTRACE constitue un autre vecteur souvent sous-estimé. Avec cette capability, un attaquant peut s'attacher (ptrace ATTACH) à n'importe quel processus du nœud hôte partageant son namespace PID, injecter du code arbitraire en mémoire, et détourner son exécution. Sur les conteneurs en mode hostPID: true, cette attaque permet de cibler directement des processus système sensibles comme sshd ou dockerd.

Container escape sur Kubernetes en 2026

Kubernetes introduit des vecteurs d'évasion supplémentaires qui vont bien au-delà de la simple sortie du conteneur vers le nœud hôte. L'objectif final d'un attaquant dans un cluster Kubernetes est généralement la compromission de l'API Server ou d'etcd, permettant un contrôle total sur l'ensemble du cluster. Notre guide de pentest Kubernetes 2026 couvre l'ensemble de la méthodologie offensive adaptée aux environnements modernes.

Le vol de ServiceAccount token est un vecteur d'attaque fréquemment sous-estimé car il ne nécessite pas de vrai container escape. Par défaut, Kubernetes monte automatiquement le token du ServiceAccount dans chaque pod via /var/run/secrets/kubernetes.io/serviceaccount/token. Si ce token dispose de permissions RBAC excessives — rôle cluster-admin ou règles autorisant des verbes comme create sur des ressources pods/exec — un attaquant ayant compromis le pod peut directement interagir avec l'API Server pour déployer des workloads malveillantes sur d'autres nœuds.

Les volumes hostPath constituent un autre vecteur majeur spécifique à Kubernetes. Un Pod avec un volume hostPath: / monte l'intégralité du système de fichiers de l'hôte. Même sans privilèges supplémentaires, cela permet la lecture de fichiers sensibles : clés privées SSH dans /root/.ssh/, tokens kubelet dans /var/lib/kubelet/, fichiers kubeconfig, ou secrets injectés par le CSI driver. La mauvaise configuration cloud native de type hostPath ouvert reste l'une des erreurs les plus critiques observées lors d'audits en 2026.

La compromission du kubelet représente également une cible de choix. Le kubelet écoute sur le port 10250 (HTTPS) et, si son authentification n'est pas correctement configurée (mode Anonymous: true), il permet l'exécution de commandes dans n'importe quel pod du nœud via l'endpoint /exec/{namespace}/{podName}/{containerName}. Une mauvaise exposition de ce port constitue une compromission directe du nœud sans même passer par un container escape traditionnel.

En 2026, les attaques visant le metadata API du cloud provider (AWS IMDS, GCP metadata server, Azure IMDS) depuis un pod compromis constituent un vecteur d'escalade redoutable. Si l'Instance Metadata Service n'est pas protégé par le mode IMDSv2 sur AWS ou par une politique de restriction réseau, un attaquant peut récupérer les credentials IAM temporaires de l'instance, donnant accès aux services cloud avec les permissions du rôle de nœud — souvent excessives dans les configurations par défaut.

Escalade de privilèges post-escape sur un cluster Kubernetes

Une fois sorti du conteneur, l'attaquant dispose généralement des droits root sur le nœud mais pas encore sur l'ensemble du cluster. Les techniques de post-exploitation visent à élargir l'impact, établir une persistance durable et compromettre des ressources cloud adjacentes. La plateforme CNAPP est précisément conçue pour détecter et bloquer ces chaînes d'escalade multi-couches.

• Lecture du kubeconfig administrateur : Le fichier /etc/kubernetes/admin.conf ou /root/.kube/config contient souvent des credentials d'accès à l'API Server avec des droits cluster-admin — compromis immédiat du cluster entier.
• Vol du token bootstrap kubelet : Les tokens kubeadm bootstrap dans /etc/kubernetes/bootstrap-kubelet.conf permettent l'authentification au cluster avec des droits d'enregistrement de nouveaux nœuds.
• Accès direct à etcd : Si etcd est accessible depuis le nœud compromis sur le port 2379 sans TLS client mutuellement authentifié, l'attaquant peut lire tous les secrets Kubernetes en clair — ServiceAccount tokens, TLS certificates, données sensibles des ConfigMaps.
• DaemonSet backdoor : Avec un accès cluster-admin obtenu via l'API Server, l'attaquant déploie un DaemonSet malveillant sur tous les nœuds, établissant une persistance robuste et difficile à éradiquer complètement.
• Cloud metadata escalation : Sur AWS, GCP ou Azure, l'endpoint de metadata (169.254.169.254) fournit des credentials IAM temporaires permettant l'escalade vers les services cloud — S3, KMS, ECR, IAM lui-même.

Détection et monitoring des container escapes en 2026

La détection des container escapes repose sur la surveillance comportementale en temps réel des appels système (syscalls). Les solutions de runtime security modernes analysent les opérations sur le système de fichiers, les connexions réseau, les modifications de processus et les appels syscall pour identifier les comportements anormaux caractéristiques d'une tentative d'évasion.

Falco, le projet CNCF de référence pour la sécurité runtime en 2026, dispose d'un ensemble de règles couvrant les principales techniques d'évasion. Les règles Container_Escape_Via_Docker_Socket, Privileged_Container, Mount_Sensitive_Host_Path et Syscall_Namespace_Change permettent de détecter les patterns d'attaque les plus courants avec une latence inférieure à la seconde. L'intégration avec des SIEM comme Elastic Security ou Splunk Enterprise Security permet une corrélation d'événements cross-couche.

En 2026, les solutions eBPF-native comme Tetragon (Cilium), KubeArmor et les modules de sécurité de Sysdig Secure permettent une observabilité granulaire des syscalls avec un impact performance minimal (moins de 3% de surcharge CPU selon les benchmarks CNCF). Ces outils constituent le socle d'une défense en profondeur efficace. Les indicateurs de compromission à surveiller prioritairement sont : exécution de nsenter, chroot, mount depuis l'intérieur d'un conteneur ; lecture de /proc/1/environ ou /proc/1/ns ; accès à /proc/sysrq-trigger ; et création de nouveaux namespaces depuis un conteneur non-privileged.

Hardening Docker contre les container escapes en 2026

Le Docker Security Cheat Sheet de l'OWASP reste la référence incontournable pour le durcissement des environnements Docker en 2026. Il convient de l'appliquer systématiquement et de le compléter avec les recommandations du CIS Docker Benchmark 1.6+ et les mises à jour liées aux vulnérabilités Leaky Vessels.

Sécuriser Kubernetes contre les container escapes en 2026

La documentation officielle Kubernetes sur la sécurité définit le modèle des 4C's of Cloud Native Security : Cloud, Cluster, Container, Code. Chaque couche doit être sécurisée indépendamment pour garantir une protection robuste. En 2026, les équipes matures adoptent une approche Shift-Left intégrant ces contrôles dès la phase de développement, dans les pipelines GitOps.

Les Pod Security Standards (PSS) constituent la première ligne de défense Kubernetes en 2026. Le niveau Restricted bloque notamment : les conteneurs privileged, les hostPath mounts, le mode hostPID/hostIPC/hostNetwork, et impose runAsNonRoot: true, allowPrivilegeEscalation: false, un profil seccomp RuntimeDefault ou Localhost, et la suppression de toutes les capabilities dangereuses. Ce niveau devrait être la norme pour tous les namespaces de production en 2026.

Le durcissement du RBAC Kubernetes est critique et souvent négligé. Les bonnes pratiques 2026 incluent : désactiver automountServiceAccountToken par défaut sur les namespaces de production, créer des ServiceAccounts dédiés avec les permissions minimales, auditer régulièrement les bindings via kubectl auth can-i --list --as=system:serviceaccount:namespace:sa-name, et supprimer les ClusterRoleBindings accordant des droits cluster-admin à des comptes applicatifs. L'outil rbac-audit automatise cette analyse dans les pipelines CI/CD.

L'admission control via OPA Gatekeeper ou Kyverno permet d'appliquer des politiques bloquant les configurations à risque avant qu'elles n'atteignent le plan de données du cluster. En 2026, l'intégration de ces outils dans les pipelines GitOps (ArgoCD, Flux) est la norme dans les environnements Kubernetes matures. Des politiques comme no-privileged-containers, restrict-hostpath-volumes, require-non-root-user et disallow-cap-sys-admin doivent être appliquées en mode deny dans les clusters de production.

Comparatif des outils de sécurité cloud-native contre les container escapes en 2026

Le marché des outils de sécurité pour les workloads conteneurisées a considérablement mûri en 2026. Les plateformes CNAPP (Cloud Native Application Protection Platform) intègrent désormais des capacités de détection runtime, d'analyse statique des images, de gestion de la posture cloud (CSPM) et de protection des workloads (CWPP) dans une interface unifiée et corrélée.

Analyse forensique d'un container escape : méthodologie 2026

Lorsqu'un incident de container escape est suspecté ou confirmé, la réponse forensique doit suivre une méthodologie rigoureuse pour préserver les preuves, évaluer l'impact réel et reconstituer la chaîne d'attaque complète. En 2026, les environnements éphémères Kubernetes rendent l'investigation forensique particulièrement complexe : les pods peuvent avoir été supprimés automatiquement par les controllers de déploiement, les logs des conteneurs effacés, et les layers de l'image filesystem ré-initialisés.

La première étape consiste à capturer l'état du système avant toute remediation. Cela implique : la capture d'un snapshot mémoire du nœud compromis (via LiME ou avml), l'export complet des logs containerd et kubelet depuis journald, la capture du trafic réseau si un agent de surveillance était actif, et la préservation des logs d'audit Kubernetes depuis l'API Server. Ces artefacts constituent la base de la reconstruction de la timeline d'attaque.

Les artefacts forensiques spécifiques aux container escapes incluent : les entrées inhabituelles dans /var/log/audit/audit.log signalant des appels mount(2), unshare(2) ou ptrace(2) depuis des processus en namespace conteneur ; les nouvelles entrées crontab dans /var/spool/cron/ ou /etc/cron.d/ ; les modifications récentes des authorized_keys SSH ; les bibliothèques inhabituelles dans /etc/ld.so.preload ; et les connexions réseau sortantes vers des adresses inhabituelles depuis le namespace réseau de l'hôte plutôt que depuis les namespaces des pods.

Checklist sécurité containers 2026 — les 15 contrôles essentiels

Pour les équipes DevSecOps souhaitant évaluer rapidement leur posture de sécurité face aux container escapes, voici les 15 contrôles essentiels à vérifier en 2026. Cette checklist est alignée avec le CIS Docker Benchmark 1.6 et le CIS Kubernetes Benchmark 1.9, références pour les audits de conformité SOC 2 Type II et ISO 27001 des environnements cloud-native. Pour une intégration dans une architecture réseau globale, consultez notre comparatif SASE/SSE 2026.

1. Aucun conteneur ne tourne avec le flag --privileged en production — contrôle via OPA Gatekeeper ou Kyverno.
2. Le socket Docker (/var/run/docker.sock) n'est jamais monté dans un conteneur applicatif — alternatives : Docker-in-Docker rootless, Kaniko, Buildah.
3. Tous les conteneurs utilisent --security-opt=no-new-privileges:true — empêche l'escalade via setuid.
4. Les profils seccomp (RuntimeDefault minimum) et AppArmor/SELinux sont actifs sur tous les workloads de production.
5. Toutes les images s'exécutent avec un UID non-root (UID > 999) — directive USER dans le Dockerfile.
6. Les capabilities Linux sont réduites au minimum via --cap-drop=ALL — jamais CAP_SYS_ADMIN sans justification documentée.
7. Le système de fichiers racine des conteneurs est en lecture seule (--read-only) avec tmpfs pour les répertoires d'écriture.
8. Les Pod Security Standards sont appliqués au niveau Restricted sur tous les namespaces de production Kubernetes.
9. Le RBAC Kubernetes est audité trimestriellement — interdiction de rôle cluster-admin sur les ServiceAccounts applicatifs.
10. L'automontage des ServiceAccount tokens est désactivé par défaut (automountServiceAccountToken: false) au niveau namespace.
11. Les volumes hostPath sont interdits en production — utiliser des StorageClass et des PVC à la place.
12. Falco ou Tetragon est déployé sur tous les nœuds du cluster avec des règles mises à jour mensuellement.
13. OPA Gatekeeper ou Kyverno valide toutes les configurations à l'admission avec des politiques en mode deny.
14. Les images sont scannées pour les CVE avant chaque déploiement — seuil de blocage sur les CVE CVSS ≥ 7.0 non patchées.
15. Le noyau Linux des nœuds est maintenu à jour — patches de sécurité critiques appliqués sous 72h, patches importants sous 7 jours.

FAQ — Container escape Docker et Kubernetes en 2026

Qu'est-ce qu'un container escape et en quoi diffère-t-il d'une VM escape ?

Un container escape désigne la capacité d'un processus à sortir de l'isolation d'un conteneur et à accéder aux ressources de l'hôte ou d'autres conteneurs. Contrairement à une VM escape, qui exploite des failles dans l'hyperviseur ou dans l'émulation matérielle, un container escape exploite des faiblesses dans les mécanismes d'isolation du noyau Linux — namespaces et cgroups — ou dans le runtime de conteneur lui-même (runc, containerd). Les conteneurs partagent le noyau de l'hôte, ce qui rend la surface d'attaque fondamentalement plus large que celle d'une machine virtuelle avec hyperviseur dédié. En 2026, cette distinction est devenue centrale dans les décisions d'architecture pour les workloads hautement sensibles : certaines organisations adoptent des runtimes conteneur isolés par hyperviseur comme gVisor ou Kata Containers (micro-VMs) pour obtenir une isolation proche de la virtualisation tout en conservant les avantages opérationnels des conteneurs.

Comment détecter qu'un container escape a eu lieu dans mon cluster Kubernetes ?

La détection d'un container escape repose sur la corrélation de plusieurs sources d'événements. Les alertes Falco ou Tetragon sur des syscalls suspects — nsenter, mount, chroot, unshare depuis un processus en namespace conteneur — constituent les signaux primaires les plus directs. Les logs d'audit Kubernetes révèlent des actions inhabituelles depuis un ServiceAccount inattendu : création de pods privileged, modification de ClusterRoleBindings, ou accès à des secrets non liés au namespace de l'application. Les logs kubelet sur le port 10250 peuvent montrer des tentatives d'exécution de commandes non initiées par le controller de déploiement. Sur le plan réseau, des connexions sortantes depuis le namespace hôte — et non depuis les namespaces réseau des pods — indiquent souvent une compromission post-escape. En 2026, l'intégration d'un pipeline SIEM corrélant toutes ces sources avec un moteur de détection comportemental est la solution la plus robuste pour les SOC avancés gérant des environnements cloud-native critiques.

Pourquoi les conteneurs privileged sont-ils encore utilisés en production malgré les risques connus ?

Les conteneurs privileged persistent en production en 2026 pour plusieurs raisons légitimes et techniques. Certains outils de monitoring système — agents de métriques noyau, profilers eBPF comme Pyroscope — nécessitent un accès direct aux primitives du noyau. Les agents CNI (Container Network Interface) comme Calico ou Cilium ont besoin de capabilities réseau avancées pour configurer les interfaces veth et les tables iptables/eBPF. Les solutions de stockage distribué comme Rook-Ceph requièrent un accès aux devices block du nœud. Enfin, certains pipelines CI/CD historiques utilisent Docker-in-Docker (DinD), qui exige le mode privileged. La bonne pratique en 2026 est de remplacer ces usages par des alternatives : agents avec capabilities minimales et profils seccomp dédiés, rootless Docker ou Buildah pour les pipelines CI, drivers CSI sécurisés pour le stockage. Quand le mode privileged reste incontournable, isolez ces workloads dans des namespaces dédiés avec NetworkPolicies strictes et monitoring Falco intensif, conformément aux principes Zero Trust appliqués aux workloads conteneurisées.

Quelle est la relation entre container escape et architecture Zero Trust / SASE en 2026 ?

Dans une architecture Zero Trust ou SASE, la sécurité des conteneurs est traitée comme un vecteur d'attaque parmi d'autres dans le modèle de risque global de l'organisation. Le principe Zero Trust appliqué aux workloads stipule qu'aucun pod ne doit faire confiance implicitement à un autre pod, même dans le même cluster ou le même namespace. Les NetworkPolicies Kubernetes, renforcées par une service mesh sécurisée avec mTLS (Istio, Linkerd), implémentent ce principe à la couche réseau et limitent drastiquement l'impact latéral d'un container escape. En complément, les solutions SSE (Security Service Edge) permettent d'inspecter et filtrer le trafic sortant des workloads conteneurisées vers Internet, bloquant les communications de commande et contrôle (C2) des malwares ayant réussi une évasion. Cette intégration des contrôles runtime avec la couche réseau Zero Trust constitue l'approche défensive la plus cohérente pour les architectures cloud-native modernes en 2026.

Conclusion

Les container escapes restent en 2026 l'une des menaces les plus critiques pesant sur les infrastructures cloud-native. La sophistication croissante des techniques d'attaque — de l'exploitation des CVE runc au vol de ServiceAccount tokens Kubernetes en passant par les abus de capabilities Linux — exige une approche défensive multicouche combinant hardening du runtime, contrôle d'admission strict, RBAC Kubernetes minimal, et monitoring comportemental en temps réel. La bonne nouvelle est que l'écosystème CNCF propose des outils open source matures permettant à toute organisation de construire une posture de sécurité robuste. L'essentiel est d'adopter une démarche proactive : tester régulièrement son propre environnement avec des outils comme kube-bench, kube-hunter et Peirates, maintenir les runtimes à jour, et intégrer la sécurité des conteneurs dans le pipeline DevSecOps dès la phase de développement — non comme un ajout a posteriori, mais comme une exigence architecturale fondamentale.