Non, les conteneurs Docker ne sont pas plus sécurisés qu'une VM.

Citant Daniel Shapira:

Rien qu'en 2017, 434 exploits du noyau Linux ont été trouvés, et comme vous l'avez vu dans cet article, les exploits du noyau peuvent être dévastateurs pour les environnements conteneurisés. En effet, les conteneurs partagent le même noyau que l’hôte, donc faire confiance aux mécanismes de protection intégrés à eux seuls n’est pas suffisant.

1. Exploits du noyau à partir d'un conteneur

Si quelqu'un exploite un bogue du noyau à l'intérieur d'un conteneur, il l'exploite sur le système d'exploitation hôte. Si cet exploit permet l'exécution de code, il sera exécuté sur le système d'exploitation hôte, pas à l'intérieur du conteneur.

Si cet exploit permet un accès arbitraire à la mémoire, l'attaquant peut modifier ou lire toutes les données de tout autre conteneur .

Sur une VM, le processus est plus long: l'attaquant devrait exploiter à la fois le noyau de la VM, l'hyperviseur et le noyau de l'hôte (et cela peut ne pas être le même que le noyau de la VM).

2. Manque de ressources

Comme tous les conteneurs partagent le même noyau et les mêmes ressources, si l'accès à certaines ressources n'est pas limité, un conteneur peut tout utiliser et affamer le système d'exploitation hôte et le d'autres conteneurs.

Sur une VM, les ressources sont définies par l'hyperviseur, donc aucune VM ne peut refuser le système d'exploitation hôte de n'importe quelle ressource, car l'hyperviseur lui-même peut être configuré pour faire une utilisation restreinte des ressources.

3. Décomposition du conteneur

Si un utilisateur à l'intérieur d'un conteneur est capable d'échapper au conteneur en utilisant un exploit ou une mauvaise configuration, il aura accès à tous les conteneurs en cours d'exécution sur l'hôte. Cela se produit parce que le même utilisateur exécutant le moteur Docker est l'utilisateur exécutant les conteneurs. Si un exploit exécute du code sur l'hôte, il s'exécutera sous les privilèges du moteur docker, afin qu'il puisse accéder à n'importe quel conteneur.

4. Séparation des données

Sur un conteneur Docker, certaines ressources ne sont pas espacées de noms:

• SELinux
• Cgroups
• systèmes de fichiers sous / sys , / proc / sys ,
• / proc / sysrq-trigger , / proc / irq , /proc/bus
• / dev / mem , / dev / sd * système de fichiers
• Modules du noyau

Si un attaquant peut exploiter l'un de ces éléments , ils seront propriétaires du système d'exploitation hôte.

Un système d'exploitation VM n'aura pas d'accès direct à aucun de ces éléments. Il parlera à l'hyperviseur et l'hyperviseur effectuera les appels système appropriés au système d'exploitation hôte. Il filtrera les appels non valides, ajoutant une couche de sécurité.

5. Sockets Raw

Le socket Docker Unix par défaut ( /var/run/docker.sock ) peut être monté par n'importe quel conteneur s'il n'est pas correctement sécurisé. Si un conteneur monte ce socket, il peut arrêter, démarrer ou créer de nouvelles images.

S'il est correctement configuré et sécurisé, vous pouvez atteindre un haut niveau de sécurité avec un conteneur docker, mais il le sera être inférieur à une VM correctement configurée. Quelle que soit la quantité d'outils de renforcement utilisés, une VM sera toujours plus sécurisée. L'isolation métallique nue est encore plus sécurisée qu'une VM. Certaines implémentations bare metal (IBM PR / SM par exemple) peuvent garantir que les partitions sont aussi séparées que si elles se trouvaient sur du matériel séparé. Pour autant que je sache, il n'y a aucun moyen d'échapper à une virtualisation PR / SM.

Dire qu'une VM ou un Docker est plus sécurisé que l'autre est une simplification excessive.

VM fournit la virtualisation matérielle; l'hyperviseur émule le matériel pour que le noyau invité pense qu'il fonctionne sur sa propre machine. Ce type de virtualisation est plus facile à isoler les uns des autres. Si votre principale préoccupation en matière de virtualisation est l'isolation (vous n'avez pas vraiment besoin que les machines virtuelles interagissent les unes avec les autres), alors la VM sera beaucoup plus simple à sécuriser.

Docker fournit la virtualisation du noyau / du système d'exploitation , et Docker utilise les espaces de noms du noyau pour virtualiser le noyau et le système d'exploitation afin que l'invité pense qu'il s'exécute sur sa propre instance du système d'exploitation. La virtualisation du système d'exploitation offre beaucoup plus de flexibilité sur la façon dont vous pouvez sécuriser l'interconnexion entre vos conteneurs. Si votre principale préoccupation en matière de virtualisation vous oblige à interconnecter des conteneurs, Docker offre la possibilité de définir ces règles de partage de manière impossible ou trop lourde avec les machines virtuelles.

Avec une grande flexibilité, de grands risques sont associés; il est plus facile de mal configurer docker que VM, et la flexibilité du partage de ressources docker crée également plus d'opportunités pour les bogues d'implémentation et de configuration. Cependant, si vous parvenez à configurer correctement les autorisations de partage et en supposant qu'il n'y a pas de bogues d'implémentation dans Docker ou le noyau, alors Docker fournit un partage beaucoup plus fin que la virtualisation matérielle et peut vous donner une meilleure sécurité globale.

Par exemple, le partage de socket. Avec Docker, vous pouvez créer facilement un socket nommé partagé entre deux conteneurs en partageant le fichier socket, et vous pouvez définir des autorisations de sécurité (à l'aide de tous les modules de sécurité existants: autorisation Unix traditionnelle, capacités, SELinux, AppArmor, seccomp, etc.) entre le points de terminaison de socket afin que le docker / noyau applique quelles applications et comment peuvent accéder aux points de terminaison de socket. Avec une machine virtuelle, vous pouvez partager un socket un peu plus encombrant en mettant en place une chaîne de sockets pour diriger les données vers le socket via TCP. Cependant, l'hyperviseur a une visibilité très limitée et aucun moyen de contrôler l'accès aux points de terminaison de socket, car les autorisations sur ces points de terminaison de socket sont appliquées par les noyaux invités.

Un autre exemple est le partage de dossiers. Avec les conteneurs, vous pouvez partager un dossier en configurant un montage partagé, et puisque le Docker / noyau applique les autorisations de fichier utilisées par les conteneurs, le système invité ne peut pas contourner ces restrictions. Avec une machine virtuelle, si vous souhaitez partager un dossier, vous devez laisser une machine exécuter un serveur de fichiers réseau ou un serveur Samba ou un serveur FTP, et l'hyperviseur a peu de visibilité sur le partage et ne peut pas appliquer les autorisations de partage. Les pièces mobiles supplémentaires ici (le serveur de fichiers) peuvent également avoir ses propres vulnérabilités et problèmes de configuration à prendre en compte.

TL; DR: Utilisez la VM pour l'isolation et les conteneurs pour le partage contrôlé.

Comme vous l'avez correctement indiqué, Docker utilise la "virtualisation au niveau du système d'exploitation". Vous pouvez considérer cela (si vous êtes un fan de * nix) comme une forme sophistiquée de chroot.

En exploitant les fonctionnalités intégrées au système d'exploitation, Docker agit en tant que directeur pour les conteneurs. La vision du logiciel du système d'exploitation est dictée par Docker.

Le même noyau est utilisé dans tous les conteneurs. Donc, par exemple, si j'étais capable de provoquer une panique du noyau dans un conteneur (pensez à "Blue Screen of Death"), tous les autres conteneurs sont affectés.

La configuration semble être beaucoup plus critique qu'avec des solutions matérielles. Tout est effectivement dans le même espace partagé. Imaginez mettre un prédateur sauvage à côté de sa source de nourriture naturelle. Si vous n’avez pas mis une enceinte suffisamment solide autour du prédateur, ou si vous avez oublié de fermer la porte à chaque fois que vous avez quitté l’enceinte, vous pouvez probablement imaginer ce qui se passerait.

Bien que ce soit certainement une solution légère, je suis certainement n'exécuterait aucun code inconnu à côté du code de confiance.

Le code malveillant devrait déterminer un moyen d'élever ses privilèges au niveau racine / administrateur afin d'échapper au conteneur de manière significative.

Dans une machine virtuelle, l'hyperviseur serait attaqué, pas le noyau. Cela peut s'avérer plus sûr car il existe un niveau d'isolation plus élevé entre les "conteneurs", mais entraîne une surcharge de gestion plus élevée.

D'après ce que je comprends, rien ne rend Docker plus sûr que le "bare metal" ou le matériel solutions. J'aurais tendance à dire que Docker est moins sécurisé. En termes de 1 conteneur par logiciel, cela peut prouver une histoire différente.

Si vous n'êtes pas sûr d'exemples du monde réel, je jetterais un œil à OpenVZ. Il utilise la virtualisation au niveau du système d'exploitation dans un style similaire à celui de Docker, mais avec un noyau modifié.

Les conteneurs Docker ne sont pas intrinsèquement «plus sûrs», mais la possibilité de faire tourner et de détruire rapidement les doublons dans un cluster est très utile du point de vue de la sécurité.

D'accord, beaucoup d'autres réponses ici mais les gens ont tendance à oublier que parfois le meilleur outil que l'on puisse utiliser pour sécuriser un serveur / une application Web est la possibilité de redéployer rapidement du code propre après que le code déjà installé a été compromis.

Rien au monde n'est sûr à 100% ou sécurise. Surtout dans le monde des applications Web exposées. Mais Docker permet de meilleures pratiques si les gens comprennent réellement leur valeur et s'engagent dans ces pratiques .

• Effectuez des sauvegardes régulières des actifs et des bases de données.
• Ayez toujours une configuration solide et portable.
• Gérez le code dans un référentiel de code.
• Utilisez un processus de déploiement qui permet le redéploiement du code en quelques touches.
• Et utilisez un outil de configuration du système pour vous assurer que les systèmes / serveurs peuvent être recréés rapidement avec un minimum d'effort.
• Si possible, déployez votre code dans une sorte de cluster à charge équilibrée, donc si une «chose» est en cours d'exécution le code est compromis, vous pouvez le tuer sans arrêter complètement l'application.

Docker s'inscrit dans le dernier point. Il en va de même pour les VM, mais Docker même les mœurs car une fois que vous avez pris la décision d'utiliser Docker, vous utilisez intrinsèquement un outil dont l'état d'esprit / mentalité est: «Je ne durerai pas éternellement. J'ai besoin d'être recréé. »

Et dans le cas d'un conteneur Docker infecté, vous pouvez le mettre hors ligne - en ce qui concerne le monde extérieur - pour effectuer des analyses pour voir ce qui s'est passé et voir ce qui peut être fait pour redéployer le code en toute sécurité sur d'autres installations de base de code existantes et nouvelles à l'intérieur des conteneurs Docker.

Les VM pourraient être en mesure d'être utilisées de cette manière, mais dans ma pratique et mon expérience, seuls les développeurs pensent vraiment de cette façon aux VM. La plupart des administrateurs système - et les équipes dont ils font partie - considèrent les machines virtuelles comme un moyen de tirer plus facilement plus d’utilisation et d’utilité d’un serveur bare metal plutôt que de les voir comme des machines rapidement jetables qui peuvent être recréées à volonté.

Avec Docker, vous devez vraiment faire tout votre possible pour faire d'un conteneur Docker un monolithe non jetable. Docker est un outil de développement d'applications conçu pour une époque où la virtualisation est rapide, bon marché et facile. Et lorsqu'il est déployé dans une sorte de cluster à charge équilibrée, vous obtenez la stabilité supplémentaire de peu ou pas de temps d'arrêt.

Je suis d'accord avec la réponse de ThoriumBR si nous comparons simplement une VM vierge avec un conteneur Docker vide. Il convient de noter, cependant, que la configuration correcte de votre système comme dans l'hôte atomique de Red Hat atténue bon nombre de ces facteurs et même en élimine certains.

De plus, depuis le démarrage de Docker, vous peut compter d'une part le nombre de types de vulnérabilités mentionnées dans sa réponse, qui pourraient toutes être atténuées par des couches supplémentaires telles que SELinux. Nous commençons également à voir des environnements d'exécution compatibles OCI basés sur l'hyperviseur, que vous pouvez utiliser à la place de runc si vous êtes vraiment paranoïaque et que vous êtes prêt à prendre un coup de performance.

Je ferai également remarquer que le vaste la majorité des vulnérabilités dans les logiciels ne se trouvent pas dans l'espace noyau / pilote où les machines virtuelles ont l'avantage de la sécurité, mais dans la couche application , où les conteneurs Docker ont l'avantage, car ils facilitent la création d'un seul processus surfaces d'attaque. Vous pouvez créer un conteneur Docker utilisable avec un seul exécutable lié statiquement qui s'exécute en tant qu'utilisateur non root, avec des ressources et des capacités limitées. Vous ne pouvez pas créer une VM avec une surface d'attaque aussi petite.

En fin de compte, vous devez regarder l'image de la sécurité dans son ensemble. Les conteneurs Docker peuvent être très sécurisés, mais vous devez examiner l'ensemble de la chaîne logistique logicielle et vous assurer de configurer correctement le docker et l'hôte. Les VM ont leur propre ensemble de forces et de faiblesses. Vous ne pouvez pas simplement comparer les deux «hors de la boîte» et prendre une décision. Vous avez besoin d'un processus en place pour durcir l'une ou l'autre solution.

La question est trop large pour être répondue par un simple "oui" ou "non".

Il existe des surfaces d'attaque très claires et ouvertes pour les conteneurs Docker:

• Si l'attaquant est celui qui peut démarrer les conteneurs (c'est-à-dire qu'il a accès à l'API Docker), alors il a immédiatement, sans autre action, un accès root complet au hôte. Ceci est bien connu depuis des années, a été prouvé et n'est discuté par personne (Google ou SE vous donneront immédiatement des lignes de commande simples qui n'ont même pas besoin d'un conteneur particulier pour fonctionner).
• Si l'attaquant parvient à obtenir root dans le conteneur, alors vous avez des problèmes. En effet, il peut alors faire des appels au noyau assez arbitraires et essayer d'affecter le noyau hôte. Malheureusement, de nombreuses images de docker semblent exécuter leur contenu en tant que root et ignorer USER dans le Dockerfile - ce n'est pas un problème de Docker mais un problème d'utilisateur.

Je vois un scénario qui rendrait en effet un système basé sur des images Docker plus sûr (peut-être ...):

• Si vous rendez religieusement vos images aussi petites que possible, et un seul par préoccupation.
• Et tous fonctionnent sans privilège (c'est-à-dire sans --privileged et pas en tant que root ).
• Et la mise en réseau est aussi étroite que possible.

Dans ce cas, ce serait probablement plus sûr qu'une solution de VM avec les paramètres suivants:

• Base installée comme petit que possible.
• Beaucoup de problèmes installés dans la même VM.
• Réseau aussi serré que possible.

La raison en est que si, par exemple , un serveur HTTP est cassé, et il s'exécute dans un conteneur minimal (et je veux dire "minimal" ici - c'est-à-dire, alpin avec rien sauf le strict minimum um, y compris pas de réseau sortant, pas de volumes rw, etc.), alors il y a moins de chance que l'attaquant puisse faire quoi que ce soit que s'il s'agissait d'une VM avec d'autres services en cours d'exécution.

De toute évidence, ce scénario suppose que les VM sont en fait plus volumineuses que les conteneurs. Si vous faites les mêmes machines virtuelles que les conteneurs, alors c'est un point discutable. Mais alors, un scénario Docker bien conçu serait conçu comme ça. Et une configuration de VM habituelle pourrait peut-être, au moins avec le temps, migrer vers de plus en plus d'éléments en cours d'installation.

Il y a déjà de bonnes réponses, mais pour avoir une illustration complète de la différence entre docker et VM je vais ajouter une image:

Source

De ce point de vue, il est plus facile de comprendre pourquoi la VM est plus sécurisée que le conteneur Docker.

Le principal argument de vente de docker n'est pas d'être plus sûr, mais d'être plus facile. Cela inclut:

• Paramètres par défaut utiles, y compris certaines options de sécurité.
• Pas de travail avec la configuration de LXC, des groupes de contrôle et ainsi de suite.
• Images prêtes à l'emploi qui peuvent être téléchargés sur une seule ligne.
• VM reproductibles. Plus d'arguments "fonctionne sur ma machine".

Docker est aussi sûr que les techniques qu'il utilise, qui sont principalement LXC (espaces de noms Linux), selinux et apparmor.

L'utilisation courante de docker est souvent terriblement peu sûre. Les gens utilisent une ligne pour télécharger une image créée par quelqu'un, ils ne lisent même jamais le nom de avant d'exécuter son conteneur de système d'exploitation. Même lorsque vous créez vous-même l'image à partir d'une propre image de base (qui peut par exemple être construite avec debootstrap de la même manière que lorsque vous construisez un chroot) et un Dockerfile, le Dockerfile inclut souvent le curl $ URL | bash anti-pattern pour installer le logiciel dans le conteneur.

Une autre chose est que "la manière docker" n'est pas de mettre à jour les images , mais pour les reconstruire. Cela signifie arrêter (les gens supposent souvent que vous avez un basculement en cours avec la nouvelle image), reconstruire et recommencer.

Cela vient de la façon dont les instantanés sont créés, où un apt-get habituel dist-upgrade introduit des couches sémantiquement bruyantes du point de vue du docker, où l'historique devrait ressembler à "baseimage", "ajouté apache", "ajouté php", "installé roundcube" sans "quotidien apt-get upgrade "entre les étapes.

Si vous maintenez un propre référentiel d'images dans votre LAN, docker peut être très utile, car vous pouvez redéployer rapidement les images mises à jour.

La fonction d'instantané est une autre chose qui peut être une bonne amélioration de la sécurité, lorsque vous pouvez rapidement restaurer ou bifurquer une image pour essayer quelque chose de nouveau dans un environnement de test, puis réinitialiser le conteneur à un état sûr.

En fin de compte, ce docker est un outil très utile pour les développeurs, qui veulent tester le déploiement de leur code reproductible et sans changer leur système d'exploitation installé, mais il existe de meilleures solutions pour la production. Vous pouvez donc exécuter docker en production en toute sécurité, mais cela ne rend pas les choses plus sûres qu'une bonne configuration LXC sans docker.

Pour autant que je sache, ils ne sont pas limités à LXC en tant que VM ou ne le seront pas restreint plus bientôt, surtout quand ils ciblent également les fenêtres. Le choix d'un autre backend a des implications sur la sécurité qui sont les mêmes que, par exemple, LXC vs KVM vs VirtualBox. Les autres points resteront probablement les mêmes.

Tout d'abord, je voudrais souligner que plus vous réutilisez / partagez les mêmes ressources, plus il est difficile de les protéger.

Cela dit, Docker essaie d'exécuter chaque processus sur un bac à sable (Container ) et c'est la seule raison pour laquelle docker peut être considéré comme plus sûr. À partir du processus multiple exécuté par votre serveur, vous aurez théoriquement accès à votre propre processus et exposerez un dossier partagé ou un socket à l'autre processus. Les fichiers de configuration, les informations d'identification, les secrets d'autres ports / sockets de débogage et de maintenance seront inaccessibles, même à partir de la même "machine".

Docker il semble plus sûr que la manière a été conçue pour travail: il bac à sable chaque processus en cours d'exécution. Là où Virtual Machines et Baremetal vous sandbox un groupe de processus et d'applications et entre eux, il est de votre responsabilité de configurer les autorisations en conséquence.