Qu'est-ce que la sécurité des conteneurs ?

Qu'est-ce que la sécurité des conteneurs ?

La sécurité des conteneurs consiste à protéger les applications conteneurisées et leur environnement sur tout leur cycle de vie : l'image construite, le registre qui la stocke, l'orchestrateur qui la déploie, le conteneur en cours d'exécution et l'hôte en dessous. Les conteneurs partagent le noyau de l'hôte et sont reconstruits souvent ; le contenu de l'image et la configuration comptent donc davantage que le durcissement d'un serveur durable. Le NIST traite le sujet dans SP 800-190, l’Application Container Security Guide.

Les cinq couches

1. Images (à la construction)

• Partir d'une image de base minimale : moins de paquets à corriger.
• Figer les versions, idéalement par digest, plutôt que d'utiliser latest.
• Analyser les images à la recherche de vulnérabilités connues en CI et faire échouer la construction au-delà d'un niveau de gravité choisi.
• Exécuter avec un utilisateur non root et ne pas mettre de secrets dans l'image.
• Signer les images et vérifier la signature avant le déploiement.

2. Registre

• Utiliser un registre privé avec contrôle d'accès et journaux d'audit.
• Ré-analyser les images stockées, car de nouvelles vulnérabilités sont publiées après le push.

3. Orchestrateur (Kubernetes)

• RBAC au moindre privilège et un compte de service distinct par charge de travail.
• Des NetworkPolicies qui refusent le trafic par défaut, puis autorisent ce dont chaque pod a besoin.
• Appliquer les Pod Security Standards de Kubernetes (Privileged, Baseline, Restricted) et préférer Restricted pour les charges applicatives.
• Des contrôleurs d'admission qui rejettent les manifestes non conformes, et la journalisation d'audit du serveur d'API.
• Secrets via l'API Secret avec chiffrement au repos, ou un gestionnaire de secrets externe.

4. Exécution

• Retirer les capabilities Linux inutiles, utiliser un système de fichiers racine en lecture seule quand l'application le permet, et éviter les conteneurs privilégiés.
• Appliquer des profils seccomp et AppArmor ou SELinux pour limiter les appels système.
• Surveiller les comportements inhabituels, comme un shell lancé dans un conteneur de production ou des connexions sortantes inattendues.

5. Hôte

• Mettre à jour le noyau et le runtime de conteneurs. Le noyau étant partagé, une faille du noyau touche tous les conteneurs du nœud.
• Utiliser un système d'hôte minimal, conçu pour les conteneurs, et restreindre les connexions directes.

Exemple

Une équipe livre un service Node sur une image de base à système complet, en root, avec le tag latest et un mot de passe de base de données dans une variable d'environnement. Passer à une image allégée figée par digest, un utilisateur non root, un système de fichiers en lecture seule, un Secret monté à l'exécution et une NetworkPolicy de refus par défaut supprime la plupart des chemins par lesquels une faille dans une dépendance mène à la base de données ou au nœud.

Erreurs courantes

• Tourner en root parce que l'image le permet par défaut.
• Tirer latest en production : une reconstruction change ce qui s'exécute sans relecture.
• Des conteneurs privilégiés « pour que ça marche », ce qui supprime l'essentiel de l'isolation.
• N'analyser qu'à la construction et ne jamais ré-analyser ce qui est déjà déployé.
• Laisser ouvert tout le trafic entre pods et sortant, si bien qu'un pod compromis atteint tout.
• Partager un compte de service trop large entre plusieurs charges.
• Configurer les clusters à la main. Les manifestes doivent être versionnés et relus comme du code ; voir l’infrastructure as code.

Notions voisines

Découper une application en microservices multiplie les images et les chemins réseau à sécuriser. L'accès des charges et des personnes doit suivre les principes de la gestion des identités et des accès, et le panorama de ce que tentent les attaquants se trouve dans menaces de cybersécurité.

Où LoadFocus intervient

LoadFocus n'est pas un produit de sécurité des conteneurs : il n'analyse pas les images, ne vérifie pas la configuration du cluster et ne détecte pas les intrusions. Il aide sur le volet performance d'une configuration durcie. Sidecars, mTLS, moteurs de politiques et agents d'exécution ajoutent de la latence et de la charge CPU, et un test de charge montre si le service tient toujours son objectif de temps de réponse au trafic attendu. La supervision d’API surveille ensuite disponibilité et rapidité des endpoints après chaque déploiement. Pour les tests de sécurité dans le cloud, voir bonnes pratiques de sécurité des tests cloud.

Questions fréquentes : sécurité des conteneurs

Les conteneurs sont-ils moins sûrs que les machines virtuelles ?

Ils isolent autrement. Les conteneurs partagent le noyau de l'hôte : une faille du noyau ou un conteneur privilégié peut toucher tout le nœud, alors qu'une machine virtuelle a son propre noyau. Les conteneurs sont plus petits et plus faciles à reconstruire et à analyser. Les deux peuvent être sûrs ou non selon la configuration.

Que corriger en premier ?

Tourner en non-root, ne plus utiliser latest et analyser les images en CI. C'est peu coûteux et cela élimine les problèmes les plus courants.

Faut-il des outils de sécurité à l'exécution ?

L'analyse à la construction ne trouve que les vulnérabilités connues. La détection à l'exécution repère des comportements que l'analyse ne voit pas, comme un shell ou une connexion sortante inattendus. Elle compte surtout pour les clusters de production sensibles.

À quoi servent les Pod Security Standards de Kubernetes ?

Ils définissent trois niveaux : Privileged (sans restriction), Baseline (bloque les élévations de privilèges connues) et Restricted (suit les pratiques actuelles de durcissement des pods). On en applique un par namespace.

L'hébergement serverless de conteneurs règle-t-il le problème ?

Il transfère la sécurité de l'hôte et de l'orchestrateur au fournisseur. Le contenu de l'image, les secrets, les permissions et les règles réseau restent de votre ressort.