Durcissement des conteneurs Docker pour l'hébergement multi-locataire : un guide d'isolation étape par étape

Résumé

L'exploitation d'une plateforme d'hébergement Docker multi-locataire nécessite une isolation hermétique des conteneurs pour empêcher les locataires d'interférer entre eux ou de s'échapper vers l'hôte. Ce guide fournit un processus de durcissement concret et étape par étape que vous pouvez appliquer dès aujourd'hui. Vous apprendrez à configurer des utilisateurs non root, à supprimer les capacités Linux inutiles, à monter les systèmes de fichiers en lecture seule, à appliquer des limites de ressources via cgroups, à segmenter les réseaux et à appliquer des profils seccomp ou AppArmor. Nous aborderons également quand augmenter les conteneurs avec des machines virtuelles pour une sécurité maximale. À la fin, vous disposerez d'une liste de contrôle pour éliminer systématiquement les vecteurs d'évasion de conteneurs courants et maintenir une véritable isolation de votre infrastructure multi-locataire.

Le problème concret des conteneurs multi-locataires

Les conteneurs Docker partagent le noyau de l'hôte, et si l'isolation est mal configurée, un locataire peut théoriquement accéder aux données d'un autre, consommer tout le CPU, ou même s'échapper vers l'hôte. En tant que fournisseur d'hébergement, vous avez besoin de frontières hermétiques sans sacrifier les avantages de performance des conteneurs. De nombreuses équipes commencent avec les paramètres Docker par défaut, qui sont conçus pour le développement, pas pour la multi-location en production. La bonne nouvelle : avec une liste de contrôle de durcissement systématique, vous pouvez verrouiller chaque conteneur à des niveaux d'isolation proches de ceux d'une VM tout en conservant la rapidité de Docker.

Cet article vous guide à travers chaque étape de durcissement avec des exemples pratiques et des mises en garde. À la fin, vous disposerez d'un processus reproductible pour déployer des conteneurs multi-locataires sécurisés.

Étape 1 : Exécuter les conteneurs en tant qu'utilisateur non root

Par défaut, les conteneurs Docker s'exécutent en tant que root. Si un conteneur est compromis, l'attaquant obtient les privilèges root à l'intérieur du conteneur et peut tenter une évasion de conteneur. Créez d'abord un utilisateur dédié dans votre Dockerfile et basculez vers celui-ci :

FROM ubuntu:22.04
RUN useradd -m appuser
USER appuser

Mise en garde : Certains processus (par exemple, la liaison à des ports < 1024) nécessitent root. Dans ces cas, utilisez le drapeau --cap-add pour n'accorder que la capacité nécessaire, comme --cap-add=NET_BIND_SERVICE, et exécutez toujours le processus sous un utilisateur non root.

Pour en savoir plus sur l'isolation fondamentale, consultez notre guide sur l'obtention d'une véritable isolation multi-locataire dans Docker.

Étape 2 : Supprimer toutes les capacités Linux et n'ajouter que ce dont vous avez besoin

Les capacités Linux décomposent les privilèges root en petites unités. Les conteneurs Docker sont livrés avec un ensemble de capacités par défaut trop permissives pour l'hébergement multi-locataire. Supprimez tout et n'ajoutez que ce que votre application nécessite :

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-app

Capacités courantes à éviter : SYS_ADMIN (évasion de conteneur), NET_RAW (écoute de paquets), SYS_PTRACE (débogage de processus). Utilisez docker run avec --security-opt no-new-privileges pour empêcher l'escalade de privilèges via des binaires setuid.

Étape 3 : Monter le système de fichiers racine en lecture seule

Les attaquants écrivent souvent des scripts malveillants dans le système de fichiers du conteneur. En rendant le système de fichiers racine en lecture seule, vous l'empêchez :

docker run --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m my-app

--tmpfs crée un montage temporaire inscriptible pour des répertoires comme /tmp et /var/run. Le drapeau noexec empêche l'exécution à partir de ce montage. Cette approche force les attaquants à passer par des répertoires inscriptibles, que vous pouvez surveiller.

Étape 4 : Appliquer des limites de ressources avec cgroups

Les conteneurs sans limites peuvent effectuer des attaques par déni de service en épuisant la mémoire ou le CPU de l'hôte. Utilisez les contraintes d'exécution de Docker :

docker run --memory=512m --memory-swap=512m --cpus=0.5 --pids-limit=100 my-app

• --memory et --memory-swap définissent des limites strictes (pas de swap).
• --cpus limite le CPU.
• --pids-limit empêche les bombes de processus en limitant le nombre de processus.

Mise en garde : Les limites de ressources sont appliquées par cgroups, mais elles n'empêchent pas l'exfiltration de données via le réseau. Combinez avec l'isolation réseau (étape suivante).

Étape 5 : Segmenter les réseaux avec les réseaux personnalisés Docker

Par défaut, les conteneurs Docker partagent un réseau pont. Dans une configuration multi-locataire, vous devez isoler la pile réseau de chaque locataire. Créez un réseau dédié par locataire :

docker network create tenant-alpha --internal
docker run --network tenant-alpha my-app

Utilisez le drapeau --internal pour bloquer l'accès Internet sortant, puis exposez uniquement les ports nécessaires via -p. Pour une segmentation réseau plus avancée, consultez sécuriser les applications web avec l'isolation Docker.

Mise en garde : Les réseaux internes empêchent la communication directe conteneur à conteneur entre locataires, mais des fuites DNS peuvent encore se produire si vous utilisez le réseau hôte. Tenez-vous en aux réseaux pont ou overlay.

Étape 6 : Appliquer les profils seccomp et AppArmor

Seccomp filtre les appels système, et AppArmor (ou SELinux) applique des contrôles d'accès obligatoires. Docker fournit un profil seccomp par défaut qui bloque les appels système dangereux comme clone avec certains drapeaux. Pour une isolation plus stricte, créez un profil personnalisé :

docker run --security-opt seccomp=./custom.json --security-opt apparmor=docker-default my-app

Vous pouvez générer un profil de base avec docker run --rm -it --security-opt seccomp=unconfined my-app strace -c -S time puis le réduire. Mise en garde : Des profils trop restrictifs peuvent casser des fonctionnalités légitimes. Testez soigneusement en préproduction.

Étape 7 : Envisager une isolation hybride avec des machines virtuelles

Si vos locataires nécessitent une isolation absolue (par exemple, secteur réglementé), exécutez des conteneurs à l'intérieur d'une VM légère. Des outils comme Sysbox ou Kata Containers offrent une séparation au niveau matériel sans sacrifier la vitesse des conteneurs. C'est l'approche utilisée par l'isolation renforcée des conteneurs (ECI) de Docker. Bien que la surcharge soit plus élevée que pour des conteneurs nus, elle est bien inférieure à celle des VM complètes par charge de travail.

Pour en savoir plus sur le choix du niveau d'isolation approprié, lisez concevoir une architecture Docker multi-locataire.

Synthèse : une liste de contrôle pour le durcissement

1. Construire des conteneurs avec un utilisateur non root.
2. Supprimer toutes les capacités, n'ajouter que celles nécessaires.
3. Monter le système de fichiers en lecture seule avec des montages temporaires inscriptibles.
4. Définir des limites de mémoire, CPU et PID.
5. Créer des réseaux Docker isolés par locataire.
6. Appliquer des profils seccomp et AppArmor personnalisés.
7. Évaluer les conteneurs VM hybrides pour les besoins de haute sécurité.

Conclusion

Le durcissement des conteneurs n'est pas une tâche ponctuelle, c'est une discipline continue. Les étapes ci-dessus constituent une base de sécurité pour l'hébergement multi-locataire. N'oubliez pas qu'aucune mesure unique ne garantit la sécurité ; la défense en profondeur est essentielle. Commencez par les bases : utilisateurs non root et capacités supprimées. Ajoutez ensuite des limites de ressources et une segmentation réseau. Pour les charges de travail les plus sensibles, combinez conteneurs et VM. Avec ce guide, vous pouvez déployer en toute confiance des environnements Docker multi-locataires à la fois efficaces et sécurisés.