10 meilleures pratiques pour la sécurité Docker

Sécurité des conteneurs Docker

La sécurité des conteneurs Docker soulève différentes inquiétudes, notamment en ce qui concerne la sécurité des fichiers Dockerfile (liés aux images de base Docker et aux éventuelles erreurs de configuration en matière de sécurité) et celle des conteneurs Docker lors de l’exécution (ports réseau, privilèges des utilisateurs, accès au système de fichiers monté sur Docker, etc.). Cet article est consacré à tous les aspects de la sécurité des conteneurs Docker se rapportant à la création d’une image Docker, à la réduction du nombre de vulnérabilités introduites par les images de base Docker ainsi qu’aux meilleures pratiques pour garantir la sécurité des Dockerfiles.

Qu’est-ce que la sécurité Docker ?

La sécurité Docker fait référence à la sécurité des conteneurs Docker lors de leur création, exécution et orchestration. Elle englobe la sécurité des Dockerfiles dans le cadre des images de base Docker, ainsi que la sécurité des conteneurs Docker en cours d’exécution, notamment les privilèges des utilisateurs, le démon Docker, les contrôles d’unité centrale appropriés d’un conteneur et d’autres aspects se rapportant à l’orchestration des conteneurs Docker à grande échelle.

La sécurité des conteneurs Docker est axée autour de 4 problèmes de sécurité majeurs :

1. Sécurité des Dockerfiles et meilleures pratiques

2. Sécurité des conteneurs Docker lors de l’exécution

3. Risques de sécurité au niveau de la chaîne d’approvisionnement dus à l’utilisation de Docker Hub et leur impact sur les images de conteneurs Docker

4. Problèmes de sécurité introduits par Kubernetes et Helm lors de l’orchestration de conteneurs « cloud native ».

Dans cette partie de notre aide-mémoire, nous aimerions nous concentrer sur la sécurité Docker et passer en revue les meilleures pratiques et directives en matière de sécurité Docker qui garantissent des images Docker sécurisées de qualité.

Consultez également notre rapport sur la sécurité Docker : Anticipation des problèmes de sécurité Docker

Passons en revue notre liste des 10 meilleures pratiques de sécurité Docker

1. Utilisez de préférence des images de base minimales

Un problème courant de sécurité des conteneurs Docker est le risque d’obtenir des images volumineuses pour vos conteneurs Docker. Le plus souvent, vous commencez un projet avec une image de conteneur Docker générique, par exemple en écrivant un Dockerfile avec un nœud FROM comme valeur par défaut. Cependant, lors de la spécification de l’image du nœud, vous devez tenir compte du fait que la distribution Debian Stretch entièrement installée est l’image sous-jacente qui est utilisée pour la construire. Si votre projet ne nécessite pas de bibliothèque ou d’utilitaire système général, il est préférable de ne pas utiliser un système d’exploitation (OS) complet comme image de base.

Dans le rapport Snyk L’état des lieux de la sécurité des logiciels open source en 2020, nous avons constaté qu’un grand nombre des conteneurs Docker les plus populaires présentés sur le site Web Docker Hub créent des images contenant de nombreuses vulnérabilités connues. Par exemple, lorsque vous utilisez une image de nœud générique qui est très souvent téléchargée, telle que celle d’un nœud d’extraction Docker, vous introduisez dans votre application un système d’exploitation complet qui comporte pas moins de 642 vulnérabilités dans ses bibliothèques système. Résultat, vous ajoutez d’emblée des problèmes de sécurité Docker inutiles.

Les dix images Docker les plus populaires contiennent chacune au moins 30 vulnérabilités.

Le rapport sur l’état des lieux de la sécurité des logiciels open source en 2020 montre que les dix principales images Docker que nous avons inspectées sur Docker Hub contenaient des vulnérabilités connues, excepté pour Ubuntu. En utilisant des images minimales ne contenant que les outils et bibliothèques système nécessaires à l’exécution de votre projet, vous minimisez également la surface d’attaque et vous avez la garantie de déployer un système d’exploitation sécurisé.

2. Utilisateur avec le moins de privilèges

Lorsqu’un Dockerfile ne spécifie pas d’utilisateur dans la variableUSER, il exécute par défaut le conteneur avec l’utilisateur racine. Dans la pratique, un conteneur est rarement doté de privilèges racines et cela pourrait être interprété comme un problème de sécurité Docker. Par défaut, Docker exécute les conteneurs avec l’utilisateur racine. Lorsque cet espace de noms est par la suite mappé à l’utilisateur racine dans le conteneur en cours d’exécution, cela signifie que le conteneur a potentiellement un accès racine sur l’hôte Docker. L’exécution d’une application sur le conteneur avec l’utilisateur racine élargit encore davantage la surface d’attaque et laisse facilement passer les attaques par escalade des privilèges si l’application elle-même est vulnérable à l’exploitation.

Pour minimiser l’exposition, optez pour la création d’un utilisateur et d’un groupe dédiés dans l’image Docker de l’application ; utilisez la directive USER dans le Dockerfile pour vous assurer que le conteneur exécute l’application avec le moins d’accès privilégiés possible.

Il est possible qu’un utilisateur spécifique n’existe pas dans l’image. Vous pouvez alors le créer en suivant les instructions figurant dans le Dockerfile. L’exemple ci-dessous montre comment procéder pour une image Ubuntu générique :

1FROM ubuntu
2RUN mkdir /app
3RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal
4WORKDIR /app
5COPY . /app
6RUN chown -R lirantal:lirantal /app
7USER lirantal
8CMD node index.js

L’exemple ci-dessus :

• crée un utilisateur système (-r) dépourvu de mot de passe, de répertoire de base défini et de shell.

• ajoute l’utilisateur que nous avons créé à un groupe existant préalablement créé (à l’aide de groupadd)

• ajoute un argument final défini sur le nom de l’utilisateur que nous voulons créer, en association avec le groupe que nous avons créé.

Si vous aimez particulièrement utiliser l’environnement d’exécution Node.js et les images basées sur Alpine, sachez qu’ils intègrent déjà un utilisateur générique appelé node. Voici l’exemple Node.js qui s’appuie sur l’utilisateur de nœud générique :

1FROM node:10-alpine 
2RUN mkdir /app
3COPY . /app
4RUN chown -R node:node /app
5USER node
6CMD [“node”, “index.js”]

Si vous développez des applications Node.js, nous vous conseillons de consulter les meilleures pratiques Docker et Node.js.

3. Signez et vérifiez les images pour réduire le risque d’attaques de l’homme du milieu

Valider l’authenticité des images Docker est un véritable défi. Nous considérons ces images comme fiables car nous les utilisons comme conteneur pour exécuter notre code dans l’environnement de production. Par conséquent, il est essentiel de s’assurer que l’image extraite est celle qui est transmise par l’éditeur, et qu’elle n’a été modifiée par aucune partie. L’image est susceptible d’être corrompue lors d’un transfert entre le client Docker et le registre, ou en compromettant le registre du compte du propriétaire afin de lui transmettre une image malveillante.

Vérifiez les images Docker

Les paramètres par défaut de Docker permettent d’extraire des images Docker sans valider leur authenticité, ce qui vous expose à des images Docker arbitraires dont l’origine et l’auteur n’ont pas été vérifiés.

Il est conseillé de toujours vérifier les images avant de les extraire, quelle que soit la politique de sécurité définie. Pour tester le processus de vérification, vous pouvez activer temporairement Docker Content Trust à l’aide de la commande suivante :

1export DOCKER_CONTENT_TRUST=1

Si vous tentez à présent d’extraire une image qui n’est pas signée, la demande sera refusée et l’image ne sera pas extraite.

Signez les images Docker

Privilégiez les images Docker certifiées provenant de partenaires de confiance qui ont été vérifiés et sélectionnés par Docker Hub plutôt que des images dont vous ne pouvez pas valider l’origine et l’authenticité.

En permettant de signer les images, Docker fournit une couche de protection supplémentaire. Pour signer des images, utilisez Docker Notary. Notary vérifie la signature de l’image afin de vous empêcher d’exécuter une image dont la signature n’est pas valide.

Lorsque Docker Content Trust est activé, comme nous l’avons vu plus haut, un build d’image Docker signe l’image. Lorsque l’image est signée pour la première fois, Docker génère et enregistre une clé privée dans ~/docker/trust pour votre utilisateur. Cette clé privée est ensuite utilisée pour signer les images qui sont créées.

Pour obtenir des instructions détaillées sur la configuration des images signées, consultez la documentation de Docker.

Quelle est la différence entre signer des images Docker à l’aide de Content Trust et Notary de Docker et signer des images à l’aide de GPG ? Diogo Mónica a présenté un exposé très intéressant sur ce sujet, mais ce qu’il faut retenir, c’est que GPG vous aide à vérifier les données, et non à déjouer les attaques par rejeu.

4. Détecter, corriger et surveiller les vulnérabilités des logiciels open source

Lorsque vous sélectionnez une image de base pour un conteneur Docker, vous vous exposez indirectement aux risques de sécurité que comporte cette image de base. Il peut s’agir de paramètres par défaut mal configurés qui ne contribuent pas à la sécurité du système d’exploitation ou de bibliothèques système fournies avec l’image de base sélectionnée.

Il est recommandé de commencer par utiliser une image de base minimale, qui ne vous empêche pas pour autant d’exécuter correctement votre application. Cela permet de réduire la surface d’attaque en limitant l’exposition aux vulnérabilités. Cependant, ce type d’image n’exécute aucun audit et ne vous protège pas non plus des futures vulnérabilités susceptibles d’être découvertes dans la version de l’image de base que vous utilisez.

C’est pourquoi l’un des meilleurs moyens de se protéger contre les vulnérabilités des logiciels de sécurité open source est d’utiliser des outils tels que Snyk, d’ajouter une analyse de sécurité Docker continue et de surveiller les vulnérabilités susceptibles d’exister dans toutes les couches des images Docker utilisées.

Vous pouvez analyser une image Docker afin de rechercher d’éventuelles vulnérabilités connues à l’aide de ces commandes :

1# fetch the image to be tested so it exists locally
2$ docker pull node:10
3# scan the image with snyk
4$ snyk test --docker node:10 --file=path/to/Dockerfile

Contrôlez régulièrement si une image Docker comporte des vulnérabilités connues pour permettre à Snyk, le cas échéant, d’envoyer des notifications et de fournir des conseils pour les corriger :

1$ snyk monitor --docker node:10

« À partir d’analyses effectuées par des utilisateurs de Snyk, nous avons constaté que 44 % des images Docker présentaient des vulnérabilités connues alors qu’il existait des images de base plus récentes et plus sécurisées. Snyk est le seul outil à fournir des conseils pour la correction des vulnérabilités détectées et permet ainsi aux développeurs de prendre des mesures et de modifier leurs images Docker. »

Snyk a également constaté que pour 20 % des images Docker analysées, le seul moyen de réduire le nombre de vulnérabilités était de reconstruire l’image.

Comment effectuer un audit de la sécurité des conteneurs Docker ?

Pour garantir la sécurité de votre environnement, il est essentiel d’analyser votre projet de conteneur basé sur Linux afin de s’assurer qu’il ne contient pas de vulnérabilités connues. Pour cela, Snyk analyse l’image de base afin de déterminer ses dépendances : Les paquets du système d’exploitation (OS) installés et gérés par le gestionnaire de paquets et les valeurs binaires des clés, à savoir les couches qui n’ont pas été installées par le gestionnaire de paquets.

Utilisez Snyk, un outil gratuit pour la sécurité des conteneurs. Sur la base des résultats de l’analyse, Snyk propose des conseils pour la correction des vulnérabilités et l’utilisation d’images publiques Docker Hub. Il indique également, entre autres détails, des recommandations concernant l’image de base ainsi que la couche Dockerfile dans laquelle une vulnérabilité a été trouvée.

5. Ne divulguez pas d’informations sensibles dans les images Docker

Lorsque vous créez une application dans une image Docker, vous pouvez parfois avoir besoin de secrets, tels qu’une clé privée SSH pour extraire du code d’un référentiel privé ou de jetons pour installer des paquets privés. Si vous les copiez dans le conteneur intermédiaire Docker, ils sont mis en cache sur la couche à laquelle ils ont été ajoutés, même si vous les supprimez par la suite. Ces jetons et clés doivent être stockés en dehors du Dockerfile.

Utilisation de builds en plusieurs étapes

La sécurité des conteneurs Docker peut également être renforcée en utilisant des builds en plusieurs étapes. Dans la mesure où Docker prend en charge les builds en plusieurs étapes, il est possible de récupérer et gérer des secrets dans une couche d’image intermédiaire qui sera ensuite éliminée afin qu’aucune donnée sensible n’atteigne le build de l’image. Vous pouvez utiliser du code pour ajouter des secrets à la couche intermédiaire, comme dans l’exemple suivant :

1FROM ubuntu as intermediate
2
3WORKDIR /app
4COPY secret/key /tmp/
5RUN scp -i /tmp/key build@acme/files .
6
7FROM ubuntu
8WORKDIR /app
9COPY --from=intermediate /app .

Utilisation des commandes de secrets de Docker

Utilisez une fonctionnalité alpha de Docker pour gérer les secrets afin de monter des fichiers sensibles sans les mettre en mémoire cache, comme dans l’exemple suivant :

Consultez le site de Docker pour en savoir plus sur les secrets.

1# syntax = docker/dockerfile:1.0-experimental
2FROM alpine
3
4# shows secret from default secret location
5RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecre
6
7# shows secret from custom secret location
8RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

Attention à la copie récursive

Soyez particulièrement attentif lorsque vous copiez des fichiers dans l’image en cours de construction. Par exemple, la commande suivante copie de manière récursive l’intégralité du dossier du contexte de construction dans l’image Docker, ce qui peut entraîner la copie de fichiers sensibles :

1COPY . .

Si votre dossier contient des fichiers sensibles, supprimez-les ou utilisez .dockerignore pour les ignorer :

1private.key
2appsettings.json

Comment protéger un conteneur Docker ?

Assurez-vous d’utiliser des constructions multi-états afin que l’image de conteneur construite pour l’environnement de production ne contienne aucun actif de développement, secret ou jeton.

De plus, assurez-vous d’utiliser un outil de sécurité de conteneurs comme Snyk qui vous permet d’analyser gratuitement vos images Docker depuis l’interface de ligne de commande, directement dans Docker Hub, ou les images déployées dans l’environnement de production à l’aide d’Amazon ECR, Google GCR ou de toute autre solution.

6. Utilisez des balises fixes pour l’immutabilité

Chaque image Docker peut avoir plusieurs balises, qui sont des variantes d’une même image. La balise la plus courante est latest, qui représente la dernière version de l’image. Les balises des images ne sont pas immuables, et l’auteur des images peut publier la même balise plusieurs fois.

Cela signifie que l’image de base de votre fichier Docker peut changer d’un build à l’autre. Cela peut entraîner un comportement incohérent en raison des modifications apportées à l’image de base. Il existe plusieurs façons d’atténuer ce problème et d’améliorer la sécurité Docker :

• Utilisez de préférence la balise la plus précise. S’il existe plusieurs balises pour une même image, telles que :8 et :8.0.1 ou même :8.0.1-alpine, utilisez de préférence la dernière version qui correspond à la référence d’image la plus spécifique. Évitez d’utiliser des balises trop génériques comme « latest ». N’oubliez pas que même si vous épinglez une balise spécifique, elle peut néanmoins être supprimée.

• Pour éviter qu’une balise d’image spécifique ne devienne indisponible et empêche les équipes de progresser, vous pouvez exécuter un miroir local de cette image dans un registre ou un compte que vous contrôlez. Il est important de prendre en compte les frais de maintenance qu’implique cette approche, car il vous faudra gérer un registre. Il est préférable de reproduire l’image que vous voulez utiliser dans un registre qui vous appartient pour vous assurer qu’elle ne change pas.

• Soyez très précis ! Au lieu d’extraire une balise, veillez à extraire une image à l’aide de la référence SHA256 spécifique à l’image Docker afin de vous assurer de toujours extraire la même image. Notez toutefois que l’utilisation d’une référence SHA256 peut être risquée, car si l’image change, ce hachage peut ne plus exister.

Les images Docker sont-elles sécurisées ?

Les images Docker peuvent être basées sur des distributions Linux open source et contenir des logiciels et des bibliothèques open source. Une récente étude sur l’état de la sécurité des logiciels open source menée par Snyk a révélé que les images Docker les plus populaires contiennent au moins 30 vulnérabilités.

7. Utilisez la commande COPY au lieu de ADD

Docker fournit deux commandes pour copier les fichiers de l’hôte vers l’image Docker lors de sa construction : COPY et ADD. Bien que similaires, ces deux instructions fonctionnent différemment et peuvent entraîner des problèmes de sécurité de conteneurs Docker :

• COPY : copie les fichiers locaux de manière récursive en fonction des fichiers ou répertoires source et de destination définis. Avec COPY, vous devez définir les emplacements.

• ADD : cette commande copie les fichiers locaux de manière récursive, crée de façon implicite le répertoire de destination s’il n’existe pas et accepte comme source des archives sous forme d’URL locales ou distantes, qu’elle développe ou télécharge respectivement dans le répertoire de destination.

Bien que subtiles, les différences entre les commandes ADD et COPY sont significatives. Tenez compte de ces différences pour éviter d’éventuels problèmes de sécurité :

• Lorsque des URL distantes sont utilisées pour télécharger des données directement dans un emplacement source, elles pourraient donner lieu à des attaques de l’homme du milieu qui modifient le contenu du fichier téléchargé. De plus, l’origine et l’authenticité des URL distantes doivent être validées. Avec la commande COPY, la source des fichiers à télécharger à l’aide des URL distantes doit être déclarée via une connexion TLS sécurisée et leur origine doit également être validée.

• Éléments à prendre en compte pour l’espace et les couches des images : l’utilisation de la commande COPY permet de séparer l’ajout d’une archive à partir d’emplacements distants et de la décomposer en différentes couches afin d’optimiser le cache des images. Lorsque des fichiers distants sont requis, l’utilisation de la commande COPY permet de les combiner en une seule commande RUN qui procède au téléchargement, à l’extraction et au nettoyage, et rend ainsi une opération à une seule couche plus efficace que toutes les couches qui auraient été nécessaires si la commande ADD avait été utilisée.

• Lorsque des archives locales sont utilisées, l’instruction ADD les extrait automatiquement pour les placer dans le répertoire de destination. Cependant, cela peut introduire des « bombes Zip » et des vulnérabilités Zip Slip qui pourraient alors être déclenchées automatiquement.

8. Utilisez des balises de métadonnées

Les balises d’image fournissent des métadonnées pour l’image que vous construisez. Elles permettent ainsi aux utilisateurs de comprendre comment utiliser l’image facilement. La balise la plus souvent utilisée est « maintainer », qui indique l’adresse électronique et le nom de la personne qui gère cette image. Ajoutez des métadonnées à l’aide de la commande LABEL :

1LABEL maintainer="me@acme.com"

Outre les informations de contact du gestionnaire de l’image, ajoutez toutes les métadonnées qui vous semblent importantes. Vous pouvez ajouter des métadonnées, telles qu’un hachage de validation, un lien vers le build approprié, l’état de la qualité (tous les tests ont-ils réussi ?), le code source, une référence à l’emplacement de votre fichier SECURITY.TXT, etc.

Il est recommandé d’utiliser un fichier SECURITY.TXT (RFC5785) qui permet d’accéder à votre politique de divulgation responsable de votre schéma de balisage Docker lors de l’ajout de balises, comme ci-dessous :

1LABEL securitytxt="https://www.example.com/.well-known/security.txt"

En savoir plus sur les balises des images Docker : http://label-schema.org/rc1/

9. Utilisez un build en plusieurs étapes pour les petites images Docker sécurisées.

Lorsque vous construisez votre application à l’aide d’un Dockerfile, de nombreux artefacts sont créés. Or, ces derniers sont nécessaires uniquement au moment de la construction. Il peut s’agir de paquets tels que des outils de développement et des bibliothèques nécessaires à la compilation, ou de dépendances nécessaires à l’exécution de tests unitaires, de fichiers temporaires, de secrets, etc.

Le fait de conserver ces artefacts dans l’image de base, qui est susceptible d’être utilisée dans l’environnement de production, a pour effet d’augmenter la taille de l’image Docker et donc potentiellement d’accroître le temps nécessaire à son téléchargement ainsi que la surface d’attaque dans la mesure où davantage de paquets sont installés. Il en va de même pour l’image Docker que vous utilisez : une image Docker spécifique peut être nécessaire pour la construction, mais pas pour l’exécution du code de votre application.

Les applications Golang constituent un excellent exemple. Pour construire une application Golang, vous avez besoin du compilateur Go. Le compilateur crée un fichier exécutable qui fonctionne sur n’importe quel système d’exploitation, sans dépendances, y compris pour les images minimales.

C’est l’une des raisons pour lesquelles Docker offre la fonctionnalité de build en plusieurs étapes. Cette fonctionnalité vous permet d’utiliser plusieurs images temporaires dans le processus de construction, en ne conservant que la dernière image et les informations que vous y avez copiées. Vous disposez ainsi de deux images :

• La première est une image de très grande taille regroupant de nombreuses dépendances utilisées pour créer votre application et exécuter des tests.

• La seconde est une image de taille très petite contenant peu de bibliothèques et une seule copie des artefacts nécessaires à l’exécution de l’application dans l’environnement de production.

10. Utilisez un linter

Utilisez un linter pour éviter les erreurs les plus courantes et établir de bonnes pratiques que les ingénieurs peuvent suivre de manière automatisée. Un linter est une tâche d’analyse de sécurité Docker particulièrement utile pour analyser de manière statique les problèmes de sécurité des Dockerfiles.

hadolint est un exemple de linter. Un linter analyse un Dockerfile et affiche un avertissement pour toute erreur qui enfreint ses règles de meilleures pratiques.

"hadolint-docker-image-security/hadolint-docker-image-security"Hadolint est encore plus puissant lorsqu’il est utilisé dans un environnement de développement intégré (IDE). Par exemple, lors de l’utilisation de hadolint en tant qu’extension VSCode, les erreurs détectées par l’outil d’analyse linter sont affichées lors de la saisie. De cette manière, il est plus facile d’écrire des Dockerfiles performants plus rapidement.

Veillez à imprimer l’aide-mémoire et à le conserver à portée de main afin de ne pas oublier certaines des meilleures pratiques permettant de garantir la sécurité des images Docker que vous créez et utilisez !

Comment durcir une image de conteneur Docker ?

Vous pouvez utiliser des linters, tels que hadolint ou dockle, pour sécuriser la configuration du Dockerfile. Assurez-vous d’analyser également vos images de conteneur pour vérifier qu’elles ne comportent pas de vulnérabilités susceptibles de compromettre sérieusement la sécurité de vos conteneurs dans l’environnement de production. Nous vous recommandons de lire le document suivant 10 meilleures pratiques pour la sécurité de vos images Docker pour garantir la sécurité de vos images.

Docker présente-t-il un risque pour la sécurité ?

Docker est une technologie de virtualisation de logiciels qui a gagné en popularité et a été largement adoptée. Il est impératif de créer et de déployer des images Docker conformément aux meilleures pratiques définies en matière de sécurité afin de limiter les vulnérabilités intégrées aux images de base Docker ou les violations de données dues à une mauvaise configuration des conteneurs Docker.

Comment sécuriser un conteneur Docker ?

Suivez les meilleures pratiques en matière de sécurité Docker afin d’utiliser des images de base Docker contenant un nombre minimal, voire nul, de vulnérabilités connues ainsi que des paramètres de sécurité Dockerfile, et surveillez les conteneurs que vous avez déployés pour vous assurer qu’aucune vulnérabilité ne soit transmise entre les environnements de développement et de production. De plus, assurez-vous de vous conformer aux meilleures pratiques de l’infrastructure en tant que code pour vos solutions d’orchestration de conteneurs.

En conclusion, si vous voulez connaître les bonnes pratiques de sécurité les plus récentes pour construire des images Docker optimales pour les applications Node.js et Java :

1. Vous êtes développeur Java ? Cette ressource vous sera particulièrement utile : Docker pour les développeurs Java : les 5 choses à savoir pour une sécurité efficace

2. 10 meilleures pratiques pour créer un conteneur Java avec Docker - Un excellent aide-mémoire très détaillé sur la façon de créer des conteneurs pouvant être déployés dans l’environnement de production pour les applications Java.

3. 10 meilleures pratiques pour conteneuriser des applications Web Node.js avec Docker - Si vous êtes développeur Node.js, vous allez adorer cette présentation étape par étape, qui vous montre comment créer des images de base Docker performantes et sécurisées pour vos applications Node.js.