Sécurité des conteneurs : renforcement des images et protection à l’exécution

Les conteneurs regroupent le code d’une application et ses dépendances dans des unités isolées qui partagent le noyau OS de l’hôte, contrairement aux machines virtuelles, qui incluent un OS invité complet. Ce partage rend les conteneurs légers et rapides, mais introduit un modèle de sécurité différent : une vulnérabilité d’évasion de conteneur pourrait permettre à un attaquant de sortir du conteneur et d’accéder directement au noyau de l’hôte, ce qui affecterait tous les autres conteneurs. La sécurité des conteneurs se concentre sur trois couches : l’image (ce qui y est intégré), l’environnement d’exécution (ce que le conteneur peut faire pendant son fonctionnement) et la plateforme d’orchestration (la manière dont les conteneurs sont gérés).

Chaque paquet installé dans une image de conteneur constitue une surface d’attaque potentielle. Le principe des images de base minimales consiste à partir de la fondation la plus petite possible : Alpine Linux (5 Mo, avec un nombre minimal de paquets), les images distroless (images de Google qui contiennent uniquement l’environnement d’exécution et l’application, sans interpréteur de commandes ni gestionnaire de paquets), ou scratch (complètement vide, pour les fichiers binaires compilés statiquement). Un conteneur dépourvu d’interpréteur de commandes empêche un attaquant qui a réussi à exécuter du code de lancer facilement wget, curl ou d’autres outils pour étendre son attaque — un principe appelé défense par exposition minimale.

Par défaut, les conteneurs Docker s’exécutent en tant que root (UID 0). Si un attaquant exploite une vulnérabilité dans l’application conteneurisée, il obtient les privilèges root à l’intérieur du conteneur. Si le conteneur partage un volume ou dispose de montages de l’hôte, root à l’intérieur du conteneur peut équivaloir à root sur l’hôte. La solution est simple : créer un utilisateur dédié dans le Dockerfile et basculer vers celui-ci avec la directive USER avant le CMD/ENTRYPOINT final. De nombreux outils d’analyse de sécurité des conteneurs signaleront comme problème toute image dépourvue d’un utilisateur sans privilèges root.

Les conteneurs immuables sont des conteneurs dont le système de fichiers ne peut pas être modifié pendant l’exécution. L’activation de --read-only dans Docker (ou de readOnlyRootFilesystem: true dans Kubernetes) empêche les attaquants d’écrire des logiciels malveillants sur le disque, de modifier des fichiers de configuration ou d’installer des outils dans un conteneur en cours d’exécution. Les applications qui doivent réellement écrire des données (journaux, fichiers temporaires) peuvent monter des volumes tmpfs spécifiques pour les écritures éphémères. Les conteneurs immuables imposent le principe selon lequel l’état d’exécution doit provenir uniquement de l’image et de la configuration, et non de modifications effectuées dans le conteneur qui contournent votre pipeline de sécurité CI/CD.

Les outils d’analyse des images de conteneurs examinent les paquets installés dans une image Docker en les comparant à des bases de données de vulnérabilités (NVD, CVE) et signalent les CVE connus. Parmi les principaux analyseurs figurent Trivy (Aqua Security, rapide et gratuit), Grype (Anchore), Snyk Container et l’analyse des images AWS ECR. L’analyse doit être intégrée au pipeline CI/CD afin que toute image présentant des CVE critiques ou élevées fasse échouer le pipeline avant son envoi vers un registre. Les analyseurs doivent également rechercher les secrets (clés d’API, mots de passe) intégrés accidentellement dans les couches de l’image.

Une erreur courante et dangereuse consiste à intégrer des secrets (clés d’API, mots de passe de base de données, certificats TLS) dans des images Docker, soit dans des variables d’environnement intégrées à l’image, soit dans des fichiers ajoutés via COPY. Ces secrets sont visibles par toute personne ayant accès à l’image, via docker history ou en extrayant les couches de l’image. Même si une couche ultérieure supprime le fichier, celui-ci reste présent dans l’historique de l’image. Les secrets doivent être injectés à l’exécution via des variables d’environnement provenant d’un gestionnaire de secrets, des secrets Docker ou des Secrets Kubernetes montés en tant que volumes.

Les outils de sécurité à l’exécution surveillent le comportement du conteneur pendant son fonctionnement et alertent en cas d’activité anormale ou la bloquent. Falco (projet CNCF) s’intègre au noyau Linux à l’aide d’eBPF ou de modules du noyau afin d’intercepter les appels système et de les comparer à des règles. Par exemple, une règle peut déclencher une alerte si un conteneur lance un shell (execve('/bin/sh')), ouvre une connexion réseau sur un port inattendu ou lit /etc/shadow. Ces indicateurs comportementaux signalent souvent une attaque en cours, même si aucun CVE connu n’a été exploité. Sysdig Secure et Aqua Security proposent des plateformes commerciales de protection à l’exécution.

Par défaut, les conteneurs Docker suppriment de nombreuses capacités Linux, mais en conservent encore davantage que nécessaire pour la plupart des applications. Les capacités répartissent les privilèges root en unités distinctes (par exemple, CAP_NET_ADMIN, CAP_SYS_ADMIN). Il est recommandé de supprimer toutes les capacités, puis de rétablir uniquement celles qui sont nécessaires avec --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Les profils Seccomp (Secure Computing Mode) définissent une liste blanche des appels système qu’un conteneur est autorisé à effectuer. Docker fournit un profil seccomp par défaut qui bloque environ 44 appels système dangereux. Des profils seccomp personnalisés pour des applications spécifiques peuvent renforcer cette restriction en bloquant tous les appels système que l’application n’utilise légitimement jamais.

Les registres de conteneurs (Docker Hub, AWS ECR, Google Artifact Registry) stockent et distribuent les images. La sécurisation du registre implique : l’activation de l’analyse des vulnérabilités lors de l’envoi, la restriction de l’accès d’envoi aux seuls comptes de service CI/CD, l’activation de la signature des images avec Sigstore/Cosign ou Docker Content Trust (Notary) afin que les environnements d’exécution ne récupèrent que des images signées cryptographiquement provenant de sources approuvées, ainsi que la configuration de l’immutabilité des images afin que les balises ne puissent pas être remplacées. Cela élimine les attaques par modification de balise, au cours desquelles un attaquant remplace une balise :latest approuvée par une image malveillante.

Les attaquants qui obtiennent la possibilité d’exécuter du code dans un conteneur peuvent tenter une évasion de conteneur pour atteindre l’hôte. Les techniques courantes incluent : l’exploitation de conteneurs privilégiés (--privileged fournit un accès presque illimité à l’hôte), l’exploitation des connecteurs Docker exposés (/var/run/docker.sock monté dans un conteneur fournit un accès complet à l’API Docker, notamment la possibilité de créer des conteneurs privilégiés) et l’exploitation de vulnérabilités du noyau par l’intermédiaire de capacités non sécurisées. Défenses : n’utilisez jamais le mode privilégié sauf nécessité absolue, ne montez jamais le connecteur Docker dans des conteneurs d’application, maintenez le noyau de l’hôte à jour et utilisez gVisor ou Kata Containers pour les charges de travail nécessitant une isolation renforcée.

Le Center for Internet Security (CIS) Docker Benchmark fournit des recommandations détaillées de configuration de sécurité pour les hôtes et les conteneurs Docker. Elles couvrent la configuration du démon, l’hygiène des images, les paramètres d’exécution des conteneurs et les contrôles réseau. Des outils comme Docker Bench for Security automatisent la vérification de conformité par rapport au référentiel CIS et produisent un rapport noté des éléments réussis ou échoués. L’exécution périodique de ce référentiel et son intégration au CI/CD garantissent que les dérives de configuration de sécurité sont détectées rapidement. Les candidats à Security+ doivent savoir que les CIS Benchmarks constituent une référence principale pour le renforcement de la sécurité des OS et des plateformes dans le contexte de l’examen.

Évaluez votre compréhension des notions de CompTIA Security+ (SY0-701) présentées dans cette leçon.

Dans cette leçon, vous avez appris que les images de base minimales et les utilisateurs non root réduisent la surface d’attaque et le niveau de privilèges des charges de travail conteneurisées, que les outils de protection à l’exécution comme Falco détectent dans les conteneurs des schémas anormaux d’appels système révélateurs d’attaques en cours, et qu’il ne faut jamais utiliser de conteneurs privilégiés ni monter le connecteur Docker dans des conteneurs d’application, car ces configurations permettent l’évasion de conteneur. Nous allons maintenant étudier la sécurité de Kubernetes, notamment RBAC, les politiques réseau et les normes de sécurité des pods.