Sécurité Docker et Kubernetes : les 10 risques

En 2026, 92 % des entreprises utilisent des containers en production (Datadog 2025). Docker et Kubernetes ne sont plus des technologies émergentes, ce sont des composants critiques de l'infrastructure. Et pourtant, la sécurité des environnements conteneurisés reste un angle mort pour beaucoup de RSSI. Le rapport Sysdig 2025 montre que 87 % des images Docker en production contiennent au moins une vulnérabilité haute ou critique.

Risque 1 : Images vulnérables

C'est le risque le plus répandu. Une image Docker qui part d'un ubuntu:22.04 non mis à jour embarque des dizaines de CVE connues. L'image node:18 officielle contient en moyenne 40+ vulnérabilités à un instant T.

• Remédiation : scanner chaque image avec Trivy ou Grype avant le déploiement ET en runtime. Utiliser des images minimales (Alpine, Distroless). Reconstruire les images au moins mensuellement.
• ThreatClaw : le skill Trivy scanne automatiquement les images de votre registry et en runtime, avec priorisation EPSS.

Risque 2 : Secrets dans les images ou l'environnement

Des clés API, mots de passe et tokens codés en dur dans les Dockerfiles, les variables d'environnement ou les layers de l'image. Trufflehog et Gitleaks trouvent encore des credentials dans 15-20 % des repos analysés.

• Remédiation : Kubernetes Secrets (chiffrés avec KMS), Vault HashiCorp, ou AWS Secrets Manager. Jamais de secret dans l'image. Utiliser des multi-stage builds pour éviter que des secrets de build ne se retrouvent dans l'image finale.

Risque 3 : Container escape

Un container mal configuré peut permettre à un attaquant de s'échapper vers le noeud hôte. Les vecteurs classiques : montage du socket Docker (/var/run/docker.sock), mode --privileged, capacités Linux excessives (CAP_SYS_ADMIN).

• Remédiation : jamais de --privileged en production. Pas de montage du socket Docker. SecurityContext Kubernetes avec runAsNonRoot: true, readOnlyRootFilesystem: true, drop de toutes les capabilities.
• ThreatClaw : le skill Docker Bench for Security vérifie automatiquement ces configurations contre les recommandations CIS.

Risque 4 : Supply chain des images

Votre image dépend de 10 images parents, 50 packages systèmes et 200 dépendances applicatives. Une seule backdoor dans la chaîne et votre container est compromis. L'attaque XZ Utils (CVE-2024-3094) a montré la réalité de ce risque.

• Remédiation : générer un SBOM (Software Bill of Materials) avec Syft. Vérifier la provenance avec Sigstore/Cosign. Utiliser un registry privé avec scan à l'admission.
• ThreatClaw : le skill Syft génère le SBOM de chaque image et le skill Grype le scanne en continu contre les nouvelles CVE.

Risque 5 : Sécurité runtime

Un container en production peut être compromis via une vulnérabilité applicative (injection SQL, SSRF, RCE). Le scan d'image détecte les vulnérabilités connues, mais pas l'exploitation en cours.

• Remédiation : monitoring des syscalls avec Falco, détection des processus anormaux, alerting sur les comportements de container inhabituels (reverse shell, mining crypto).
• ThreatClaw : la détection comportementale ML s'applique aussi aux containers, baseline de processus, réseau et filesystem par container.

Risque 6 : Network policies absentes

Par défaut, tous les pods Kubernetes peuvent communiquer entre eux. Pas de segmentation, pas de micro-segmentation. Un attaquant qui compromet un pod frontend peut atteindre le pod database directement.

• Remédiation : implémenter des NetworkPolicies Kubernetes. Principe de deny-all par défaut, puis autoriser explicitement les flux nécessaires. CNI compatible (Calico, Cilium).

Risque 7 : RBAC mal configuré

Kubernetes RBAC est puissant mais complexe. Les erreurs classiques : ClusterRoleBinding avec cluster-admin sur des comptes de service, wildcards (*) dans les permissions, ServiceAccounts par défaut avec trop de droits.

• Remédiation : principe du moindre privilège. Auditer régulièrement les RBAC bindings. Utiliser des outils comme kubiscan ou rakkess pour visualiser les permissions effectives.

Risque 8 : Logging et monitoring insuffisants

Sans logs centralisés, un incident dans un cluster Kubernetes est quasi impossible à investiguer. Les pods sont éphémères, quand ils crashent, les logs disparaissent.

• Remédiation : stack de logging centralisé (EFK/ELK, Loki). Audit logs Kubernetes activés. Rétention suffisante pour le forensic (90 jours minimum). Intégration avec votre SIEM.

Risque 9 : Non-conformité réglementaire

Les environnements conteneurisés doivent respecter les mêmes exigences que le reste de l'infrastructure : NIS2, RGPD, PCI DSS, ISO 27001. Mais les contrôles traditionnels (agents sur les serveurs, scan de ports) ne fonctionnent pas de la même façon dans un cluster Kubernetes.

• Remédiation : adapter les contrôles de conformité au paradigme container. CIS Kubernetes Benchmark. Admission controllers (OPA Gatekeeper, Kyverno) pour enforcer les politiques à l'admission.

Risque 10 : Backup et disaster recovery

Les workloads stateless sont faciles à recréer. Les données persistantes (PersistentVolumes, bases de données stateful) le sont moins. Un ransomware qui chiffre les PV d'un cluster peut être aussi dévastateur qu'un ransomware sur un serveur traditionnel.

• Remédiation : Velero pour le backup des ressources Kubernetes + snapshots des PV. Tests de restauration réguliers. Backup hors cluster (règle 3-2-1). Détection ransomware sur les PV.

Les skills ThreatClaw pour la sécurité container

ThreatClaw intègre des skills spécialisés pour les environnements Docker et Kubernetes :

• Trivy : scan d'images (CVE, secrets, misconfigs), scan filesystem, scan de config Kubernetes
• Grype : analyse SCA (Software Composition Analysis) des dépendances dans les images
• Docker Bench for Security : audit CIS Docker Benchmark automatisé
• Syft : génération SBOM pour la traçabilité supply chain

Ces skills tournent en continu. Chaque nouvelle image poussée dans le registry est scannée. Chaque dérive de configuration est alertée. Le RSSI a une visibilité temps réel sur la posture de sécurité container, pas un snapshot mensuel.

FAQ

Docker est-il intrinsèquement moins sécurisé qu'une VM ?

Non, mais le modèle de sécurité est différent. Les containers partagent le kernel de l'hôte, ce qui réduit l'isolation par rapport à une VM. Cependant, avec les bonnes pratiques (seccomp, AppArmor/SELinux, namespaces, capabilities réduites), un container correctement configuré offre une surface d'attaque réduite. Le risque est surtout dans la mauvaise configuration, pas dans la technologie.

Faut-il scanner les images à chaque build ou seulement en production ?

Les deux. Le scan au build (CI/CD pipeline) empêche les images vulnérables d'atteindre la production. Le scan en runtime détecte les nouvelles CVE publiées après le déploiement. Une image propre au jour J peut devenir vulnérable le lendemain si une nouvelle CVE est découverte dans une de ses dépendances.

Kubernetes est-il nécessaire pour les petites infrastructures ?

Non. Pour moins de 20 containers, Docker Compose ou Docker Swarm suffisent souvent. Kubernetes apporte de la valeur à partir de 50+ containers, surtout si vous avez besoin d'auto-scaling, de rolling updates et de multi-node. La complexité de Kubernetes est un coût : plus de surface d'attaque, plus de misconfiguration possible. Choisissez la complexité dont vous avez besoin, pas plus.

Comment sécuriser un cluster Kubernetes existant en priorité ?

Par ordre de priorité : (1) scanner toutes les images en production avec Trivy, corriger les CVE critiques. (2) Activer les NetworkPolicies deny-all et ouvrir les flux nécessaires. (3) Auditer le RBAC et supprimer les permissions excessives. (4) Activer les audit logs et les centraliser. (5) Implémenter un admission controller (Kyverno ou OPA Gatekeeper). ThreatClaw couvre les étapes 1 à 4 automatiquement.