Sécurité des conteneurs.

La sécurité des conteneurs couvre tout le cycle de vie des conteneurs OCI (Docker, containerd, CRI-O). Au build, les équipes scannent les images à la recherche de CVE et de secrets, les signent avec Sigstore/Cosign et imposent des images de base minimales. À la distribution, les registres sont protégés par authentification et vérification de signatures. Au runtime, durcissement de l'hôte, isolation namespaces/cgroups, seccomp, AppArmor et systèmes de fichiers en lecture seule réduisent la surface d'attaque, tandis que les admission controllers et sondes eBPF appliquent les politiques et détectent les anomalies.

Les conteneurs partageant le noyau de l'hôte, une seule faille du noyau ou du runtime peut briser l'isolation. CVE-2019-5736 permettait à une image malveillante d'écraser le binaire runc de l'hôte via /proc/self/exe, offrant une exécution de code root sur le nœud ; corrigée dans runc 1.0-rc7 et Docker 18.09.2. En 2024, « Leaky Vessels » CVE-2024-21626 fuyait un descripteur de fichier interne (fd/7) pointant vers le répertoire de travail de l'hôte avant pivot_root, si bien que fixer le cwd du conteneur à /proc/self/fd/7 permettait de sortir du rootfs (corrigée dans runc 1.1.12). Comme une évasion de pod équivaut souvent à la compromission du nœud, la défense en profondeur est cruciale : retirer les capabilities, exécuter en non-root, éviter les montages privilégiés et hostPath, garder runc à jour et envisager des sandbox plus robustes comme gVisor ou Kata Containers.

flowchart LR
  A[Build : scanner + signer l'image] --> B[Registre : authn + verifier signature]
  B --> C[Admission : refuser privilegie/hostPath]
  C --> D[Runtime : seccomp, AppArmor, non-root, caps retirees]
  D --> E[Detection : alertes eBPF/Falco]
  D -. faille noyau/runc .-> X[Evasion du conteneur vers l'hote]
  X -. attenuee par .-> F[Sandbox gVisor / Kata]