Une traduction de l'article a été préparée spécialement pour les étudiants du cours Linux Security .
Dans cet article, nous aimerions nous concentrer sur Docker et discuter de trucs et astuces qui fournissent un processus plus sécurisé et de haute qualité pour le traitement des images Docker.
Commençons donc par notre liste de 10 meilleures pratiques de sécurité d'image Docker.
1. Préférez des images de base minimales
Vous pouvez souvent démarrer des projets avec une image de conteneur Docker de base, par exemple, en écrivant un
Dockerfile avec le
FROM node «par défaut». Cependant, lorsque vous spécifiez une image de nœud, gardez à l'esprit que la distribution Debian Stretch entièrement installée est l'image de base qui est utilisée pour la construire. Si votre projet ne nécessite aucune bibliothèque ou utilitaire système commun, il est préférable d'éviter d'utiliser un système d'exploitation (OS) entièrement fonctionnel comme image de base.
Dans
le rapport sur l'état de la sécurité de Snyk Open Source 2019, nous avons constaté que de nombreux conteneurs Docker populaires présentés sur le site Web Docker Hub contiennent des images qui contiennent de nombreuses vulnérabilités connues. Par exemple, lorsque vous utilisez l'image populaire de
docker pull node universel, vous entrez réellement le système d'exploitation dans votre application, qui, comme vous le savez, a 580 vulnérabilités dans ses bibliothèques système.
Comme vous pouvez le voir dans le rapport de sécurité, chacune des dix images Docker les plus populaires que nous avons testées dans le Docker Hub contenait des vulnérabilités connues. Préférant des images minimales qui combinent uniquement les outils système et les bibliothèques nécessaires pour exécuter votre projet, vous réduisez également l'espace pour les attaquants à attaquer et assurez-vous de fournir un système d'exploitation sécurisé.
EN SAVOIR PLUS SUR LA SÉCURITÉ DE VOS IMAGES2. Utilisateur le moins privilégié
Lorsque le
Dockerfile ne spécifie pas
USER , par défaut, le conteneur s'exécute en tant qu'utilisateur root. En pratique, il y a très peu de raisons pour lesquelles un conteneur doit avoir des privilèges root. Docker démarre les conteneurs par défaut en utilisant l'utilisateur root. Ensuite, lorsque cet espace de noms est mappé à l'utilisateur racine dans un conteneur en cours d'exécution, il s'ensuit que le conteneur a potentiellement un accès root sur l'hôte Docker. L'exécution de l'application dans un conteneur avec un utilisateur racine étend encore l'espace d'attaque et fournit un moyen facile d'élever les privilèges si l'application elle-même est vulnérable aux exploits.
Pour minimiser l'exposition, activez la création d'un utilisateur et d'un groupe dédiés dans l'image Docker pour l'application; utilisez la directive
USER dans le
Dockerfile pour vérifier que le conteneur démarre l'application avec l'accès le moins privilégié.
Un utilisateur dédié peut ne pas exister dans l'image; créez cet utilisateur en suivant les instructions du
Dockerfile .
Voici un exemple complet de la façon de procéder pour une image Ubuntu universelle:
FROM ubuntu RUN mkdir /app RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal WORKDIR /app COPY . /app RUN chown -R lirantal:lirantal /app USER lirantal CMD node index.js
Exemple ci-dessus:
- crée un utilisateur système (-r) sans mot de passe, sans installer de répertoire personnel et sans shell
- ajoute l'utilisateur que nous avons créé au groupe existant que nous avons créé à l'avance (en utilisant groupadd)
- ajoute le dernier argument au nom de l'utilisateur que nous voulons créer, en combinaison avec le groupe que nous avons créé
Node.js et images alpines, ils incluent déjà un utilisateur générique appelé
node . Voici un exemple Node.js utilisant le nœud utilisateur générique:
FROM node:10-alpine RUN mkdir /app COPY . /app RUN chown -R node:node /app USER node CMD [“node”, “index.js”]
Si vous développez des applications Node.js, vous pouvez vous référer aux
meilleures pratiques officielles
Docker et Node.js.3. Signez et vérifiez les images pour éviter les attaques MITM
L'authenticité des images Docker est un problème. Nous nous appuyons sur ces images car nous les utilisons littéralement comme un conteneur qui exécute notre code en production. Par conséquent, il est important de s'assurer que l'image que nous utilisons est exactement celle fournie par l'éditeur et qu'aucune des parties ne l'a modifiée. La contrefaçon peut se produire via une connexion filaire entre le client Docker et le registre, ou en piratant le registre du compte du propriétaire pour remplacer l'image.
Validation d'une image Docker
Les paramètres Docker par défaut vous permettent de récupérer des images Docker sans vérifier leur authenticité, ce qui pourrait potentiellement conduire à l'utilisation d'images Docker dont l'origine et l'auteur ne sont pas vérifiés.
Il est recommandé de toujours vérifier les images avant de les utiliser, quelle que soit la politique. Pour tester la validation, activez temporairement Docker Content Trust avec la commande suivante:
export DOCKER_CONTENT_TRUST=1
Essayez maintenant d'afficher l'image dont vous savez qu'elle n'est pas signée - la demande sera rejetée et l'image ne sera pas reçue.
Images Docker Signature
Préférez
les images
certifiées Docker de partenaires de confiance qui ont été vérifiées et supervisées par le Docker Hub plutôt que les images dont vous ne pouvez pas vérifier l'origine et l'authenticité.
Docker vous permet de signer des images et offre ainsi un autre niveau de protection. Pour signer des images, utilisez
Docker Notary . Le notaire vérifie la signature de l'image pour vous et bloque le lancement de l'image si la signature de l'image n'est pas valide.
Lorsque le Docker Content Trust est activé, comme nous l'avons montré ci-dessus, l'assemblage de l'image Docker signe l'image. Lorsque l'image est connectée pour la première fois, Docker crée et stocke la clé privée dans
~/docker/trust pour votre utilisateur. Cette clé privée est ensuite utilisée pour signer toutes les images supplémentaires lors de leur création.
Pour des instructions détaillées sur la configuration des images signées, consultez la
documentation officielle de Docker .
4. Recherchez, corrigez et suivez les vulnérabilités des composants open source
Lorsque nous sélectionnons l'image de base pour notre conteneur Docker, nous prenons indirectement le risque de tous les problèmes de sécurité auxquels l'image de base est associée. 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, ainsi que des bibliothèques système associées à l'image de base que nous avons choisie.
Une bonne première étape consiste à utiliser l'image de base minimale possible pour exécuter l'application sans problème. Cela permet de réduire l'espace d'attaque en limitant la vulnérabilité; d'autre part, il n'effectue aucune de ses propres vérifications et ne vous protège pas des futures vulnérabilités qui pourraient être identifiées pour la version utilisée de l'image de base.
Par conséquent, une façon de se protéger contre les vulnérabilités des logiciels open source consiste à utiliser des outils tels que Snyk pour ajouter une analyse et un suivi continus des vulnérabilités pouvant exister dans toutes les couches d'images Docker utilisées.
Une image Docker est analysée à la recherche de vulnérabilités connues à l'aide de ces commandes:
L'image Docker est surveillée pour détecter les vulnérabilités connues, afin qu'après avoir découvert de nouvelles vulnérabilités dans l'image Snyk, elle puisse notifier et fournir des recommandations sur la façon de la corriger, comme suit:
$ snyk monitor --docker node:10
Sur la base de l'analyse effectuée par les utilisateurs de Snyk, nous avons constaté que 44% des analyses d'images Docker révélaient des vulnérabilités connues et pour lesquelles des images de base plus récentes et plus sécurisées étaient disponibles. Cette consultation de correctif, par laquelle les développeurs peuvent prendre des mesures et mettre à jour leurs images Docker, est unique à Snyk.
Snyk a également constaté que pour 20% de toutes les numérisations d'images Docker, seule la reconstruction de l'image Docker est suffisante pour
réduire les vulnérabilités . En savoir plus sur le nombre de rapports de sécurité 2019 ouverts sur le blog Snyk.
La fin de la première partie.
Suite dans la deuxième partie , et maintenant nous invitons tout le monde à un webinaire gratuit sur le sujet: «Vulnérabilités Docker. Échappez du conteneur à l'hôte avec une escalade de privilèges . »