Docker Security
PreviousD-Bus Enumeration & Command Injection Privilege EscalationNextAbusing Docker Socket for Privilege Escalation
Last updated
Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui:
Le moteur Docker utilise les espaces de noms et les Cgroups du noyau Linux pour isoler les conteneurs, offrant une couche de sécurité de base. Une protection supplémentaire est assurée par la suppression des capacités, Seccomp, et SELinux/AppArmor, améliorant l'isolation des conteneurs. Un plugin d'authentification peut restreindre davantage les actions des utilisateurs.
Le moteur Docker peut être accédé localement via un socket Unix ou à distance en utilisant HTTP. Pour un accès à distance, il est essentiel d'utiliser HTTPS et TLS pour garantir la confidentialité, l'intégrité et l'authentification.
Le moteur Docker écoute par défaut sur le socket Unix à unix:///var/run/docker.sock. Sur les systèmes Ubuntu, les options de démarrage de Docker sont définies dans /etc/default/docker. Pour permettre l'accès à distance à l'API et au client Docker, exposez le démon Docker sur un socket HTTP en ajoutant les paramètres suivants:
Cependant, exposer le démon Docker via HTTP n'est pas recommandé en raison de problèmes de sécurité. Il est conseillé de sécuriser les connexions en utilisant HTTPS. Il existe deux approches principales pour sécuriser la connexion :
Le client vérifie l'identité du serveur.
Le client et le serveur s'authentifient mutuellement.
Des certificats sont utilisés pour confirmer l'identité d'un serveur. Pour des exemples détaillés des deux méthodes, consultez ce guide.
Les images de conteneurs peuvent être stockées dans des référentiels privés ou publics. Docker propose plusieurs options de stockage pour les images de conteneurs :
Docker Hub : Un service de registre public de Docker.
Docker Registry : Un projet open source permettant aux utilisateurs d'héberger leur propre registre.
Docker Trusted Registry : Offre commerciale de Docker, proposant une authentification des utilisateurs basée sur les rôles et une intégration avec les services d'annuaire LDAP.
Les conteneurs peuvent présenter des vulnérabilités de sécurité soit en raison de l'image de base, soit en raison des logiciels installés par-dessus l'image de base. Docker travaille sur un projet appelé Nautilus qui effectue une analyse de sécurité des conteneurs et répertorie les vulnérabilités. Nautilus fonctionne en comparant chaque couche d'image de conteneur avec un référentiel de vulnérabilités pour identifier les failles de sécurité.
Pour plus d'informations, lisez ceci](https://docs.docker.com/engine/scan/).
docker scan
La commande docker scan vous permet de scanner les images Docker existantes en utilisant le nom ou l'ID de l'image. Par exemple, exécutez la commande suivante pour analyser l'image hello-world :
La signature des images Docker garantit la sécurité et l'intégrité des images utilisées dans les conteneurs. Voici une explication condensée :
Pour activer la confiance du contenu Docker, définissez export DOCKER_CONTENT_TRUST=1. Cette fonctionnalité est désactivée par défaut dans Docker version 1.10 et ultérieure.
Avec cette fonctionnalité activée, seules les images signées peuvent être téléchargées. Le premier envoi d'image nécessite de définir des phrases secrètes pour les clés racine et de balisage, Docker prenant également en charge Yubikey pour une sécurité renforcée. Plus de détails peuvent être trouvés ici.
Tenter de télécharger une image non signée avec la confiance du contenu activée entraîne une erreur "No trust data for latest".
Pour les envois d'images suivants, Docker demande la phrase secrète de la clé du dépôt pour signer l'image.
Pour sauvegarder vos clés privées, utilisez la commande :
Lorsque vous passez d'un hôte Docker à un autre, il est nécessaire de déplacer les clés root et de dépôt pour maintenir les opérations.
Utilisez Trickest pour construire facilement et automatiser des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui à :
Les espaces de noms sont une fonctionnalité du noyau Linux qui partitionne les ressources du noyau de telle sorte qu'un ensemble de processus voit un ensemble de ressources tandis qu'un autre ensemble de processus voit un ensemble différent de ressources. La fonctionnalité fonctionne en ayant le même espace de noms pour un ensemble de ressources et de processus, mais ces espaces de noms font référence à des ressources distinctes. Les ressources peuvent exister dans plusieurs espaces.
Docker utilise les espaces de noms du noyau Linux suivants pour atteindre l'isolation des conteneurs :
espace de noms pid
espace de noms de montage
espace de noms réseau
espace de noms ipc
espace de noms UTS
Pour plus d'informations sur les espaces de noms, consultez la page suivante :
NamespacesLa fonctionnalité du noyau Linux cgroups fournit la capacité de restreindre les ressources telles que le CPU, la mémoire, l'E/S, la bande passante réseau parmi un ensemble de processus. Docker permet de créer des conteneurs en utilisant la fonctionnalité cgroup qui permet le contrôle des ressources pour le conteneur spécifique. Voici un conteneur créé avec une mémoire d'espace utilisateur limitée à 500m, une mémoire noyau limitée à 50m, une part de CPU à 512, un poids de blkioweight à 400. La part de CPU est un ratio qui contrôle l'utilisation du CPU du conteneur. Il a une valeur par défaut de 1024 et une plage entre 0 et 1024. Si trois conteneurs ont la même part de CPU de 1024, chaque conteneur peut utiliser jusqu'à 33% du CPU en cas de contention des ressources CPU. blkio-weight est un ratio qui contrôle l'E/S du conteneur. Il a une valeur par défaut de 500 et une plage entre 10 et 1000.
Pour obtenir le cgroup d'un conteneur, vous pouvez faire :
Pour plus d'informations, consultez :
CGroupsLes capacités permettent un contrôle plus fin des capacités pouvant être autorisées pour l'utilisateur root. Docker utilise la fonctionnalité de capacité du noyau Linux pour limiter les opérations pouvant être effectuées à l'intérieur d'un conteneur indépendamment du type d'utilisateur.
Lorsqu'un conteneur Docker est exécuté, le processus abandonne les capacités sensibles que le processus pourrait utiliser pour s'échapper de l'isolation. Cela vise à garantir que le processus ne pourra pas effectuer d'actions sensibles et s'échapper :
Linux CapabilitiesIl s'agit d'une fonctionnalité de sécurité qui permet à Docker de limiter les appels système pouvant être utilisés à l'intérieur du conteneur :
SeccompAppArmor est une amélioration du noyau pour confiner les conteneurs à un ensemble limité de ressources avec des profils par programme :
AppArmorSystème d'étiquetage : SELinux attribue une étiquette unique à chaque processus et objet de système de fichiers.
Application des politiques : Il applique des politiques de sécurité définissant les actions qu'une étiquette de processus peut effectuer sur d'autres étiquettes dans le système.
Étiquettes de processus de conteneur : Lorsque les moteurs de conteneurs lancent des processus de conteneurs, ils se voient généralement attribuer une étiquette SELinux confinée, couramment container_t.
Étiquetage de fichiers dans les conteneurs : Les fichiers à l'intérieur du conteneur sont généralement étiquetés container_file_t.
Règles de politique : La politique SELinux garantit principalement que les processus avec l'étiquette container_t ne peuvent interagir (lire, écrire, exécuter) qu'avec des fichiers étiquetés container_file_t.
Ce mécanisme garantit que même si un processus à l'intérieur d'un conteneur est compromis, il est confiné pour interagir uniquement avec des objets ayant les étiquettes correspondantes, limitant ainsi considérablement les dommages potentiels de telles compromissions.
SELinuxDans Docker, un plugin d'autorisation joue un rôle crucial en matière de sécurité en décidant d'autoriser ou de bloquer les demandes au démon Docker. Cette décision est prise en examinant deux contextes clés :
Contexte d'authentification : Cela inclut des informations complètes sur l'utilisateur, telles que son identité et la manière dont il s'est authentifié.
Contexte de commande : Il comprend toutes les données pertinentes liées à la demande en cours.
Ces contextes garantissent que seules les demandes légitimes d'utilisateurs authentifiés sont traitées, renforçant la sécurité des opérations Docker.
AuthZ& AuthN - Docker Access Authorization PluginSi vous ne limitez pas correctement les ressources qu'un conteneur peut utiliser, un conteneur compromis pourrait provoquer un DoS sur l'hôte où il s'exécute.
DoS CPU
Déni de service de bande passante
Sur la page suivante, vous pouvez apprendre ce que signifie le drapeau --privileged:
Si vous exécutez un conteneur où un attaquant parvient à accéder en tant qu'utilisateur à faibles privilèges. Si vous avez un binaire suid mal configuré, l'attaquant pourrait l'exploiter et escalader les privilèges à l'intérieur du conteneur. Ce qui pourrait lui permettre de s'en échapper.
Exécuter le conteneur avec l'option no-new-privileges activée empêchera ce type d'escalade de privilèges.
Pour plus d'options --security-opt, consultez: https://docs.docker.com/engine/reference/run/#security-configuration
Il est crucial d'éviter d'intégrer directement des secrets dans les images Docker ou d'utiliser des variables d'environnement, car ces méthodes exposent vos informations sensibles à toute personne ayant accès au conteneur via des commandes telles que docker inspect ou exec.
Les volumes Docker sont une alternative plus sûre, recommandée pour accéder à des informations sensibles. Ils peuvent être utilisés comme un système de fichiers temporaire en mémoire, atténuant les risques associés à docker inspect et à la journalisation. Cependant, les utilisateurs root et ceux ayant un accès exec au conteneur pourraient toujours accéder aux secrets.
Les secrets Docker offrent une méthode encore plus sécurisée pour gérer des informations sensibles. Pour les cas nécessitant des secrets lors de la phase de construction de l'image, BuildKit présente une solution efficace avec la prise en charge des secrets au moment de la construction, améliorant la vitesse de construction et fournissant des fonctionnalités supplémentaires.
Pour tirer parti de BuildKit, il peut être activé de trois manières :
Via une variable d'environnement : export DOCKER_BUILDKIT=1
En préfixant les commandes : DOCKER_BUILDKIT=1 docker build .
En l'activant par défaut dans la configuration Docker : { "features": { "buildkit": true } }, suivi d'un redémarrage de Docker.
BuildKit permet l'utilisation de secrets au moment de la construction avec l'option --secret, garantissant que ces secrets ne sont pas inclus dans le cache de construction de l'image ou dans l'image finale, en utilisant une commande comme :
Pour les secrets nécessaires dans un conteneur en cours d'exécution, Docker Compose et Kubernetes offrent des solutions robustes. Docker Compose utilise une clé secrets dans la définition du service pour spécifier les fichiers secrets, comme le montre un exemple de docker-compose.yml:
Cette configuration permet l'utilisation de secrets lors du démarrage des services avec Docker Compose.
Dans les environnements Kubernetes, les secrets sont nativement pris en charge et peuvent être gérés plus en détail avec des outils comme Helm-Secrets. Les contrôles d'accès basés sur les rôles (RBAC) de Kubernetes améliorent la sécurité de la gestion des secrets, de manière similaire à Docker Enterprise.
gVisor est un noyau d'application, écrit en Go, qui implémente une partie substantielle de la surface du système Linux. Il inclut un runtime de l'Open Container Initiative (OCI) appelé runsc qui fournit une frontière d'isolation entre l'application et le noyau hôte. Le runtime runsc s'intègre avec Docker et Kubernetes, facilitant l'exécution de conteneurs sandbox.
Kata Containers est une communauté open source travaillant à construire un runtime de conteneur sécurisé avec des machines virtuelles légères qui se comportent et fonctionnent comme des conteneurs, mais offrent une isolation de charge de travail plus forte en utilisant la technologie de virtualisation matérielle comme une deuxième couche de défense.
Ne pas utiliser le drapeau --privileged ou monter un socket Docker à l'intérieur du conteneur. Le socket Docker permet de lancer des conteneurs, c'est donc un moyen facile de prendre le contrôle total de l'hôte, par exemple, en exécutant un autre conteneur avec le drapeau --privileged.
Ne pas exécuter en tant que root à l'intérieur du conteneur. Utiliser un utilisateur différent et les espaces de noms utilisateur. Le root dans le conteneur est le même que sur l'hôte sauf s'il est remappé avec les espaces de noms utilisateur. Il est seulement légèrement restreint par, principalement, les espaces de noms Linux, les capacités et les cgroups.
Supprimer toutes les capacités (--cap-drop=all) et n'activer que celles qui sont nécessaires (--cap-add=...). Beaucoup de charges de travail n'ont pas besoin de capacités et les ajouter augmente la portée d'une attaque potentielle.
Utiliser l'option de sécurité “no-new-privileges” pour empêcher les processus de gagner plus de privilèges, par exemple via des binaires suid.
Limitez les ressources disponibles pour le conteneur. Les limites de ressources peuvent protéger la machine contre les attaques de déni de service.
Utiliser des images Docker officielles et exiger des signatures ou construire les vôtres basées sur elles. Ne pas hériter ou utiliser des images contenant des portes dérobées. Stocker également les clés racines, les phrases secrètes dans un endroit sûr. Docker a des plans pour gérer les clés avec UCP.
Reconstruisez régulièrement vos images pour appliquer les correctifs de sécurité à l'hôte et aux images.
Gérez vos secrets de manière judicieuse pour qu'il soit difficile pour l'attaquant d'y accéder.
Si vous exposez le démon Docker, utilisez HTTPS avec une authentification client et serveur.
Dans votre Dockerfile, privilégiez COPY à la place de ADD. ADD extrait automatiquement les fichiers zippés et peut copier des fichiers à partir d'URL. COPY n'a pas ces capacités. Dans la mesure du possible, évitez d'utiliser ADD pour ne pas être vulnérable aux attaques via des URL distantes et des fichiers Zip.
Avoir des conteneurs séparés pour chaque micro-service.
Ne pas mettre ssh à l'intérieur du conteneur, “docker exec” peut être utilisé pour ssh vers le conteneur.
Avoir des images de conteneurs plus petites.
Si vous êtes à l'intérieur d'un conteneur Docker ou avez accès à un utilisateur dans le groupe docker, vous pourriez essayer de vous échapper et d'élever les privilèges:
Docker Breakout / Privilege EscalationSi vous avez accès au socket Docker ou avez accès à un utilisateur dans le groupe docker mais que vos actions sont limitées par un plugin d'authentification Docker, vérifiez si vous pouvez le contourner:
AuthZ& AuthN - Docker Access Authorization PluginL'outil docker-bench-security est un script qui vérifie des dizaines de bonnes pratiques courantes autour du déploiement de conteneurs Docker en production. Les tests sont tous automatisés et sont basés sur le CIS Docker Benchmark v1.3.1. Vous devez exécuter l'outil à partir de l'hôte exécutant Docker ou d'un conteneur avec suffisamment de privilèges. Découvrez comment l'exécuter dans le README: https://github.com/docker/docker-bench-security.
Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
