Blog
Une checklist pratique de sécurité d'isolation Docker pour l'hébergement multi-tenant
Sécurisez votre hébergement Docker multi-tenant avec cette checklist pratique couvrant les utilisateurs non-root, les capacités, seccomp, les espaces de noms utilisateur, les limites de ressources et les systèmes de fichiers en lecture seule.
Résumé
L'hébergement Docker multi-tenant nécessite une isolation solide pour empêcher les évasions de conteneurs. Cet article fournit une checklist de sécurité pratique couvrant six domaines clés : exécuter en tant que non-root, supprimer les capacités, appliquer des profils seccomp, activer le remappage des espaces de noms utilisateur, définir des limites de ressources et utiliser des systèmes de fichiers racine en lecture seule. Chaque étape comprend un exemple de configuration concret pour Docker Compose. Vous apprendrez également les pièges courants, comme les problèmes de compatibilité du noyau avec les espaces de noms utilisateur et les compromis de performance lors de l'application de seccomp. En suivant cette checklist, vous pouvez réduire considérablement la surface d'attaque sans ajouter de complexité inutile. L'article se termine par une configuration de base recommandée pour les environnements multi-tenant de production.
Si vous gérez un environnement Docker multi-tenant, le spectre d'une attaque d'évasion de conteneur vous empêche de dormir. Une seule exploitation du noyau peut sortir d'un conteneur et donner à un attaquant un accès complet à l'hôte et aux données de tous les autres locataires. Bien que Docker fournisse des primitives d'isolation puissantes — espaces de noms, cgroups et capacités — une mauvaise configuration laisse des failles. Cet article présente une checklist de sécurité étape par étape que vous pouvez appliquer dès aujourd'hui. Chaque étape comprend un extrait fonctionnel de Docker Compose et des mises en garde essentielles. À la fin, vous disposerez d'une base durcie qui équilibre sécurité et performance.
1. Exécuter les conteneurs en tant qu'utilisateur non-root
Par défaut, les conteneurs s'exécutent en tant que root à l'intérieur du conteneur. Si un attaquant obtient les droits root dans le conteneur, il a une longueur d'avance pour s'échapper. Définissez toujours un utilisateur non-root dans votre Dockerfile.
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
Dans Compose, vous pouvez également définir l'utilisateur directement :
services:
app:
image: myapp
user: "1000:1000"
Avertissement : Certaines applications nécessitent root pour des opérations légitimes (par exemple, la liaison à des ports inférieurs à 1024). Utilisez CAP_NET_BIND_SERVICE au lieu d'exécuter tout le conteneur en tant que root. Pour un aperçu plus approfondi des fondamentaux de l'isolation, consultez notre guide sur l'isolation multi-tenant véritable dans Docker.
2. Supprimer toutes les capacités et n'ajouter que ce qui est nécessaire
Les capacités Linux offrent des privilèges granulaires aux conteneurs. Par défaut, Docker accorde un ensemble de capacités. Supprimez tout et n'accordez que celles qui sont requises.
services:
app:
image: myapp
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE # si nécessaire
Avertissement : Les capacités comme SYS_ADMIN ou NET_RAW sont rarement nécessaires. Auditez votre application pour déterminer l'ensemble minimal. Supprimer toutes les capacités bloque de nombreux vecteurs d'évasion.
3. Appliquer un profil seccomp
Seccomp (mode de calcul sécurisé) filtre les appels système disponibles pour un conteneur. Docker est livré avec un profil seccomp par défaut qui bloque les appels système dangereux comme clone avec certains indicateurs. Vous pouvez le personnaliser davantage.
services:
app:
image: myapp
security_opt:
- seccomp=/path/to/custom-profile.json
Un profil durci pourrait bloquer unshare, ptrace et mount. Commencez avec le profil par défaut de Docker et restreignez davantage. Avertissement : Des profils trop stricts peuvent casser les applications. Testez minutieusement dans un environnement de staging. Pour en savoir plus sur les défenses contre les évasions de conteneurs, lisez se défendre contre l'évasion de conteneurs.
4. Activer le remappage des espaces de noms utilisateur
Les espaces de noms utilisateur mappent l'utilisateur root du conteneur à un utilisateur hôte non privilégié. Cela signifie que même si un attaquant obtient root à l'intérieur du conteneur, il n'a aucun privilège spécial sur l'hôte.
Activez-le sur le démon Docker en éditant /etc/docker/daemon.json :
{
"userns-remap": "default"
}
Redémarrez ensuite Docker. Avertissement : Le remappage des espaces de noms utilisateur présente deux inconvénients : il casse les montages de volumes s'ils ne sont pas configurés avec soin (les fichiers appartiennent à l'utilisateur remappé) et est incompatible avec certains pilotes de stockage comme overlay2 sur les noyaux plus anciens. Testez minutieusement.
5. Définir des limites de ressources avec cgroups
Les limites de ressources empêchent un conteneur compromis de lancer une attaque par déni de service contre l'hôte. Utilisez les cgroups pour limiter le CPU, la mémoire et les E/S disque.
services:
app:
image: myapp
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
Pour Docker Compose v3, utilisez la section deploy (fonctionne avec swarm ou compose v2). Pour Docker simple, utilisez --memory et --cpus. Avertissement : Des limites trop basses peuvent provoquer des kills OOM. Surveillez l'utilisation et ajustez en conséquence.
6. Utiliser un système de fichiers racine en lecture seule
Un système de fichiers racine en lecture seule empêche les attaquants d'écrire des binaires malveillants ou de modifier des fichiers de configuration à l'intérieur du conteneur.
services:
app:
image: myapp
read_only: true
tmpfs:
- /tmp:noexec,nosuid,size=64m
Montez tmpfs sur les répertoires qui nécessitent un accès en écriture (comme /tmp). Cela force toutes les données modifiables à être éphémères. Avertissement : Certaines applications nécessitent un stockage persistant ; utilisez des volumes nommés pour cela.
Pièges courants
- Compatibilité du noyau : Le remappage des espaces de noms utilisateur et certaines règles seccomp nécessitent un noyau Linux récent (4.14+). Vérifiez votre version du noyau.
- Impact sur les performances : Seccomp et les espaces de noms utilisateur ajoutent une légère surcharge, mais elle est négligeable pour la plupart des charges de travail. Évaluez les performances de votre application spécifique.
- Complexité : Ajouter les six mesures à la fois peut casser des choses. Appliquez-les une par une, testez chaque changement.
Pour une vue plus large des modèles d'orchestration, consultez notre guide sur la conception d'une architecture Docker multi-tenant.
Conclusion
Un hôte Docker multi-tenant sécurisé ne nécessite pas d'outils exotiques — seulement une utilisation correcte des fonctionnalités intégrées de Docker. Commencez par un utilisateur non-root, supprimez toutes les capacités, appliquez un profil seccomp, activez le remappage des espaces de noms utilisateur, définissez des limites de ressources et utilisez un système de fichiers en lecture seule. Cette checklist constitue une base solide qui bloque les techniques d'évasion les plus courantes. Après la mise en œuvre, exécutez des outils de sécurité comme docker-bench-security pour vérifier votre configuration. N'oubliez pas : la sécurité est un processus, pas un produit. À mesure que de nouvelles vulnérabilités du noyau apparaissent, revoyez vos paramètres. Pour des pages d'atterrissage automatisées qui présentent votre service d'hébergement, utilisez Pagenza pour mettre votre site en ligne en quelques minutes.
Sources (5)
- Docker and Container Isolation
- Chapter 2. Container Hosts and Multi-tenancy | Container Security Guide | OpenShift Container Platform | 3.6 | Red Hat Documentation
- What is Container Escape? - Aqua Security
- Container escape vulnerabilities allow attackers to break out of isolated environments and gain unauthorized access to host systems.
- Enhanced Container Isolation - Docker Docs

