Est-il sûr de faire confiance à un conteneur Docker?
En ce qui concerne Docker, il est très pratique d'utiliser un conteneur tiers qui existe déjà pour faire ce que nous voulons. Le problème est que ces conteneurs peuvent être très compliqués et avoir un grand arbre parent d'autres conteneurs; ils peuvent même extraire du code de référentiels comme GitHub. Tout cela complique un audit de sécurité.
Je sais que cela peut sembler naïf, mais pourrait-il être facile pour quelqu'un de cacher du contenu malveillant dans un conteneur? Je sais que la réponse est OUI mais je voudrais savoir dans quelle dimension et si cela vaut le risque. Je connais bien GitHub et je regarde généralement le code source lorsque j'utilise du code tiers (sauf s'il s'agit d'un projet bien connu).
Je me demande si la communauté surveille ce type de comportement, car le mal d'un conteneur malveillant pourrait être plus important que du code malveillant.
Quelle est la probabilité qu'un conteneur soit malveillant? (Étant donné qu'il s'agit d'un modèle populaire.) De même, quelles dimensions pourraient endommager/utiliser les autres composants du système de soulignement ou les autres systèmes du réseau local? Pour être encore plus simple, dois-je leur faire confiance?
Edit: J'ai trouvé un article de Docker qui apporte un peu de lumière sur la sécurité et les meilleures pratiques de Docker: Comprendre la sécurité et les meilleures pratiques de Docker .
Pour le moment, il n'y a aucun moyen de déterminer facilement s'il faut faire confiance à des conteneurs Docker spécifiques. Il existe des conteneurs de base fournis par Docker et les fournisseurs de systèmes d'exploitation qu'ils appellent "fiables", mais le logiciel ne dispose pas encore de bons mécanismes (par exemple, la signature numérique) pour vérifier que les images n'ont pas été falsifiées.
Pour plus de précisions, citons la publication récente Norme de sécurité CIS pour docker section 4.2
Les référentiels officiels sont des images Docker organisées et optimisées par la communauté Docker ou le fournisseur. Mais, la fonctionnalité de signature et de vérification d'image de conteneur Docker n'est pas encore prête.
Par conséquent, le moteur Docker ne vérifie pas lui-même la provenance des images de conteneur.
Vous devez donc faire preuve d'une grande prudence lors de l'obtention d'images de conteneurs.
Lorsque vous entrez dans le monde des conteneurs tiers généraux à partir du hub Docker, l'image est encore plus délicate. Le docker AFAIK ne pas vérifie les fichiers conteneurs d'autres personnes, donc il y a un certain nombre de problèmes potentiels
- Le conteneur contient des logiciels malveillants réels. Est-ce probable, personne ne le sait. Est-ce possible, oui.
- Le conteneur contient un logiciel non sécurisé. Les Dockerfiles sont essentiellement comme des scripts batch qui construisent une machine. J'en ai vu plusieurs qui font des choses comme télécharger des fichiers sur des connexions HTTP non chiffrées, puis les exécuter en tant que root dans le conteneur. Pour moi, ce n'est pas un bon moyen d'obtenir un conteneur sécurisé
- Le conteneur définit des paramètres non sécurisés. Docker consiste à automatiser la configuration des logiciels, ce qui signifie que vous faites, dans une certaine mesure, confiance à toutes les personnes qui ont créé les fichiers docker pour les avoir configurés de manière aussi sécurisée que vous l'auriez souhaité.
Bien sûr, vous pouvez vérifier tous les fichiers docker, mais une fois que vous avez fait cela, vous auriez presque mieux fait de configurer la chose vous-même!
Quant à savoir si cela "vaut le risque", je crains que ce soit une décision que vous seul pouvez vraiment prendre. Vous échangez le temps nécessaire pour développer et maintenir vos propres images, contre les risques accrus qu'une personne impliquée dans la production du logiciel que vous téléchargez soit malveillante ou se soit trompée en matière de sécurité du système.
Faites-lui confiance autant que tout code non signé que vous exécutez sur vos systèmes. Les conteneurs ne sont que des processus avec des protections d'espace de noms supplémentaires, c'est donc toutes les protections qu'ils obtiennent. Ils parlent toujours au même noyau en dessous.
Il est préférable de considérer qu'un conteneur Docker est identique à l'exécution d'une application sur le système hôte. Il y a quelques tentatives pour verrouiller le démon Docker en supprimant les capacités du noyau Linux, mais ce n'est pas vraiment une garantie. Si vous exécutez Docker, vous pouvez prendre certaines mesures pour atténuer certains de ces risques.
- SELinux - L'activation de cela générera automatiquement une étiquette MCS pour chaque conteneur, limitant sa capacité à faire des dégâts.
- Lecture seule - Vous pouvez également marquer le conteneur en lecture seule, ce qui vous permet de créer de grandes portions de l'image du conteneur en lecture seule, ce qui peut le rendre plus difficile pour un attaquant de déployer un malware.
- Registre auto-hébergé - Pour réduire le risque de falsification d'image, de chargement de conteneurs malveillants, de divulgation de secrets ou de vous exposer à des risques, vous pouvez héberger un registre en interne . https://github.com/dogestry/dogestry est un exemple de celui qui se trouve au-dessus de S3, bien qu'il existe également d'autres options.
En substance, je soutiens que c'est la même question que de savoir si un logiciel open source est fiable. Mais je pense que le risque d'utiliser des conteneurs Docker communautaires est actuellement un peu plus élevé que les risques d'utiliser un logiciel open source.
Premièrement, comme vous l'avez mentionné, il n'y a pas de signature et de vérification maintenant. Les bons systèmes d'emballage open source incluent aujourd'hui cela , au moins lors de l'obtention de logiciels à partir de dépôts officiels. Et même les projets ponctuels ont tendance à inclure des sommes de contrôle dans les bundles de téléchargement. Donc, dans le monde open source, vous ne savez pas que le code est sûr, mais vous savez souvent que vous obtenez le code que vous êtes censé obtenir. Avec Docker, vous ne savez même pas que le conteneur est inchangé entre la publication et votre téléchargement.
La deuxième est la question du paquet lui-même. Êtes-vous sûr que le logiciel ne fait rien de mal, comme signaler vos activités à une destination Internet? Ceci était une peur commune des logiciels open source . De nos jours, de nombreuses grandes entreprises ne remettent pas en cause les implémenteurs techniques qui intègrent des logiciels open source. On peut dire que n logiciel source fermé pourrait être pire de cette façon. Mais pour un conteneur Docker, en particulier celui qui comprend un ensemble complet d'outils et de bibliothèques de système d'exploitation, la "surface d'attaque" est bien plus grande. Si vous pensez que vous utilisez peut-être une mauvaise version de postfix, obtenez simplement le code officiel et compilez-le (et certains gestionnaires de paquets le font normalement). Si vous pensez que vous avez un mauvais conteneur Docker, c'est souvent un peu une aventure de reproduire l'image "à partir de la source".
Pouvez-vous faire confiance aux conteneurs dockers SECURITY? Je pense que la réponse à cette question doit presque toujours être NON!
Dans mon cas, je me pose des questions sur 'linuxserver/openvpn-as'. Gee, ne serait-il pas agréable de simplement insérer cette chose dans l'un de mes essaims de dockers, de l'ouvrir à mes réseaux privés et de le laisser gérer l'accès des utilisateurs distants à ces réseaux. Mais comment puis-je faire confiance à quelque chose comme ça à n'importe quel conteneur que je quitte du Web et qui n'a aucune provenance? Sans cela, je ne pense pas pouvoir.
Si j'avais la provenance, je n'aurais qu'à faire confiance au créateur pour avoir
- a commencé avec quelque chose de tout aussi fiable (et ainsi de suite et ainsi de suite),
- pas fait quelque chose de malveillant, et
- pas fait un choix dangereux pour une étape d'installation ou de configuration.
C'est un ordre assez grand en soi. Dans ce cas, je dois faire confiance à linuxserver.io. Jamais entendu parler d'eux. Mais en les regardant, il semble que leur travail consiste à créer des conteneurs. Ils sont donc probablement très bons dans ce domaine. Et ce conteneur aurait été téléchargé depuis DockerHub plus de 500K fois. Cela ressemble à quelque chose d'assez sûr.
Donc je pourrais probablement me sentir bien si je pouvais être sûr que l'image que je reçois
- a été créé par linuxserver.io, et
- c'est en fait l'image qui a vraiment été téléchargée 500K fois.
Eh bien, tout d'abord, (2) n'est pas vrai, non? Cela compte toutes les versions du conteneur, je crois. Alors peut-être que le conteneur est sûr depuis des années, mais quelqu'un JUSTE a sorti une version avec une sérieuse faille de sécurité. Et puis il y a (1). Voilà le vrai puant. Combien d'autres mécanismes dois-je faire confiance (DockerHub, l'hôte de DockerHub, l'infrastructure Internet, ...) pour être sûr que le code source d'origine du conteneur que linuxserver.io considère comme la source du conteneur définit vraiment complètement le conteneur que j'utilise réellement. Je ne peux pas le savoir. Et, vraiment, je devrais savoir cela non seulement à propos de ce conteneur, mais à propos de tous les sous-conteneurs utilisés pour le créer. Je ne peux donc pas utiliser ce conteneur.
C'est un cas extrême, mais probablement pas pour tout conteneur impliquant la sécurité du réseau. Je m'attends à ce que bon nombre de ces 500 000 consommateurs qui ont réellement utilisé cette image l'ont fait de manière imprudente, sans faute de linuxserver.io.
Docker a besoin d'un mécanisme complet de provenance des conteneurs. Même alors, il y a une énorme confiance à rassembler ici. Peut-être trop énorme. Peut-être que les logiciels de sécurité ne sont tout simplement pas capables de conteneuriser.
Vous pouvez établir la confiance dans la source par une enquête rapide, mais une préoccupation plus fondamentale est l'immaturité relative du profil de sécurité global, comme le suggère la nécessité d'utiliser l'accès root pour exécuter votre conteneur.
Puisque vous suggérez que nous nous concentrions sur des solutions populaires, considérons que nous utilisons un référentiel Git contrôlé comme Docker Hub pour dérouler un produit populaire fourni par le fournisseur. Les mécanismes Git offrent une bonne couche de confiance. Si vous faites confiance au fournisseur nommé, vous pouvez faire confiance à son produit Docker. Si vous vous souvenez il y a quelques années, GitHub a été compromis mais le code source était correct en raison du mécanisme de signature d'intégrité et des contrôles de publication de Git. Ces fonctionnalités protègent également les fichiers publiés Docker si vous utilisez des produits de fournisseurs populaires.
Le Dockerfile qui construit votre conteneur peut atteindre et télécharger des fichiers tar, etc. qui ne sont pas hébergés sur des référentiels Git approuvés. Une simple vérification de ce fichier texte, le Dockerfile, peut renforcer la confiance dans cet espace.
Les mécanismes de sécurité globaux sont très jeunes, veuillez donc considérer leurs vulnérabilités en plus des problèmes de contrôle des sources. De leur documentation sur la sécurité:
Il y a trois domaines principaux à considérer lors de l'examen de la sécurité Docker:
- la sécurité intrinsèque du noyau et sa prise en charge des espaces de noms et des groupes de contrôle
- la surface d'attaque du démon Docker lui-même
- des failles dans le profil de configuration du conteneur, soit par défaut, soit personnalisées par les utilisateurs
- les fonctions de sécurité "renforcées" du noyau et leur interaction avec les conteneurs
Je pense que le fait que leur première page sur la sécurité indique qu'il y a trois domaines principaux et en énumère quatre est une autre indication que les choses évoluent dans cet espace. Cela semble être une solution fantastique mais peut nécessiter un durcissement intelligent avec les périmètres et politiques fournis par l'utilisateur à court terme.
Avec Docker en particulier, d'après mon expérience, vous pouvez faire confiance à la grande majorité des éléments de la communauté open source (comme des éléments sur Github) pour ne pas être délibérément malveillants. Vous pouvez lire le Dockerfile et vérifier qu'il extrait le code des dépôts officiels le cas échéant (par opposition à l'utilisation d'une fourchette de personne aléatoire). Si cela tire du code d'un endroit étrange, bien sûr, vous pouvez toujours jeter un œil à ce qui est différent du dépôt officiel dans cette fourchette spécifique. C'est là que vous entrez dans un logiciel malveillant qui n'est pas intentionnellement malveillant. C'est juste du code de merde ou une configuration horrible ou équivalent. D'après mon expérience avec Docker, le code qui utilise des fourches non officielles doit être évité, sauf si le fork fournit une fonctionnalité spécifique que vous recherchez. Le dépôt officiel va être mis à jour plus souvent que la fourchette, presque partout. En outre, Docker utilise ce que l'on appelle des "builds de confiance" afin que vous sachiez que vous obtenez ce qu'il dit que vous obtenez sur l'étain. Enfin, Docker lui-même a présenté des vulnérabilités. Il semble que vous ayez la bonne mentalité pour vous donner un sentiment d'intestin si quelque chose semble mal.
En moins de mots, généralement si vos ressources Docker tirent FROM une version officielle, et à partir des dépôts officiels, c'est à peu près aussi sûr que vous pouvez utiliser un logiciel. Docker lui-même a eu son lot de vulnérabilités, mais tant que vous restez au courant des correctifs de votre infrastructure, vous ferez bien.
Supposons la position par défaut de ne pas faire confiance à tout ce que vous souhaitez apporter à votre environnement de l'extérieur.
Si c'est quelque chose que vous voulez vraiment utiliser, minimisez le risque autant que possible en le séquestrant, en l'analysant et en vous assurant qu'il ne fera aucun mal.
Donnez-lui le moins d'accès possible à votre environnement afin de lui permettre de faire ce dont vous avez besoin.
Vérifiez-le. Mettez-le à jour et assurez-vous que les mises à jour n'introduisent pas de nouveau risque.