Aujourd'hui pas de technique, mais l'histoire d'un tweet qui m'a donné envie de réagir pendant mes vacances bien méritées ( ou pas ! ).

Initialement je souhaitais vous parler de tout ça  en août, mais faute de temps, je n'ai pas pu ...
Depuis j'ai dû lancer plusieurs centaines de container pour différents tests et j'ai utilisé plein de belles images ... Et le moins qu'on puisse dire : ça a renforcé mon idée que cet article était nécessaire !

Commençons tout d'abord par le tweet en question :

Si vous n'êtes pas motivés pour lire l'intégralité du tweet et des commentaires, voici un rapide résumé :

  • Un utilisateur souhaite utiliser une image du Docker Hub,
  • Cette image se base sur une autre image ...
  • Mais celle-ci n'est pas à jour car elle se base "encore" sous alpine 3.6 qui n'est plus maintenue depuis le 01 Mai 2019 :
  • Problématique qui met en avant les problèmes de sécurité :
  • Et enfin la complexité de retrouver une image source :

Alors en quoi ce tweet me fait-il réagir ?

Un utilisateur expérimenté peut déjà avoir du mal à retrouver certaines informations et détecte en plus des éléments de sécurité qui sont pour le moins ... non négligeable.

Mais si je suis un débutant dans l'utilisation des containers et que je vois ça, je me sauve en courant ?

Fuyez !

Attendez encore un peu, on va essayer d'y voir plus clair ! 😀

La jungle des images

En réalité ce tweet est criant de vérité sur deux sujets :

  • La clarté de l'information, la reproductibilité ...
  • La sécurité des images.

Pour le premier point, j'aurais même envie d'évoquer le mot "qualité".

Si toi aussi tu as besoin d'image Docker pour ton travail ( pour effectuer des tests par exemple ) et que non, tu n'as pas le temps de tout "rebuild" car :

On va essayer de voir ensemble les pièges à éviter lors de la première utilisation d'une image. Ici pas question de devenir des experts de la sécurité, cet article à pour but de fournir aux plus grand nombres ( et surtout aux débutants ) quelques pistes...

Docker Hub

Le Docker Hub, c'est l'endroit pour trouver des images :

  • https://hub.docker.com/

Je ne vais pas présenter l'outil car si vous êtes ici, je pense que vous le connaissez déjà un minimum !

Mais voilà on y trouve beaucoup de choses, plus ou moins maintenues ...

Je ne vais pas vous fournir une checklist exhaustive qui va vous garantir que l'image que vous souhaitez utiliser est sans risque, mais plutôt quelques conseils pour éviter les mauvaises surprises !

Avant toute chose, et pour être très clair, la seule et unique règle lorsque vous utilisez un dépôt d'image publique doit rester :

  • Il y a toujours un risque ...

1/ Vérifier l'auteur de l'image :

Je vous invite tout d'abord à utiliser autant que possible les images qui portent l'une des mentions suivantes :

Elles vont garantir un minimum de vérification de la part des équipes de Docker sur les auteurs de l'image.

Exemple avec les images de Traefik :

Ne fuyez pas pour autant les images de la communauté. Mais soyez juste encore plus vigilant lorsque vous devez utiliser une image "non officielle".

J'attire juste d'ailleurs l'attention sur une donnée que l'on pourrait croire révélatrice de la qualité d'une image :

🚩 Le nombre de téléchargement d'une image n'est pas un gage de qualité ! 🚩

Je vous invite d'ailleurs à lire l'article mis en avant dans la partie sécurité un peu plus bas dans cette page pour comprendre très rapidement pourquoi.

2/ Dockerfile :

Deuxième point essentiel dans ma recherche d'image sur le Hub. L'accès simple et rapide au fichier Dockerfile :

Traefik Dockerfile

C'est un gage de transparence qui est important. Vous pouvez ainsi facilement retrouver le cheminement de la création de l'image.

Alors certes il faudra sûrement faire quelques recherches sur le Hub pour retrouver une image construite à partir d'une autre car ...

Pas de secret pour cette partie, si votre image utilise une autre image comme base de départ ( autrement dit dès que vous n'avez pas l'instruction FROM scratch en début de fichier ), il va falloir inspecter le(s) différent(s) Dockerfile.

Docker : l’image scratch, c’est quoi ?
Si comme moi tu as regardé la saison 3 de Dark sur Netflix et que tu t’es demandé ensuite ce qui était à l’origine de toutes tes images Docker, alors bienvenue sur cet article !
Loïc FACHELa Grotte du Barbu

Cela vous permettra de vous assurer du contenu présent dans votre image : Quels sont les fichiers ajoutés avec ADD ou COPY par exemple ? Les scripts de démarrage ? Les paquets utilisés ?

Attention toutefois, la présence du fichier Dockerfile ( surtout uniquement en lien dans le Readme ) ne peut pas garantir à elle seule l'origine de votre image... Même avec ces éléments en poche, il est important de rester vigilant !

3/ Présentation/documentation de l'image :

Soyons honnête une grande partie du problème se situe dans l'interface chaise/clavier... Et dans le manque parfois flagrant de documentation autour de l'image que l'on souhaite utiliser.

Ce point rejoins fortement le précédent mais trouver une image avec une documentation claire et lisible depuis le Hub est également un plus dans vos recherches :

C'est clair, non ?

Un readme moins étoffé n'est pas forcément un gage d'une mauvaise image ( et sa présence n'est pas un gage de sécurité, soyons clair ) mais pour la reproductibilité et la clarté de l'information on repassera :

ou pas ...

Je m'impose ces même règles lors de la création de dépôt git et d' images registry en interne pour mes labs et/ou missions.

Vous pouvez d'ailleurs retrouver un article intéressant sur le sujet de la documentation technique ( avec une expérience Docker en plus ) :

  • https://www.jesuisundev.com/ecris-ta-documentation-technique-bordel-de-merde/

Malgré tout ces gages de qualités ( qui ne sont pas des éléments de sécurité, j'insiste ! ) que nous avons pu mettre en avant ici, je vous invite à avoir une approche zero trust.

Donc même si les étoiles sont correctement alignées et que tout semble parfait, je vais tout de même vérifier quelques éléments de sécurités !

Sécurité

L'un des problèmes fréquents posés par les technologies de conteneurisation, c'est la sécurité de l'image : Est-elle à jour ? Comporte t-elle des failles ?

Hélas le problème de la mise à jour des images est fréquent et sûrement le problème le plus visible.

Je ne peux  - que vous inviter - à être vigilant sur les images que vous utilisez et je vous rappelle l'article que j'avais pu écrire sur les différents scanners de vulnérabilités :

Scanner les vulnérabilités de ses conteneurs
De plus en plus utilisés, car ils nous facilitent la tâche, les conteneurs ne sont pourtant pas exempts de défauts, comme par exemples des failles de sécurité. Avez-vous vérifié la sécurité de la dernière image que vous avez déployée ?
Loïc FACHELa Grotte du Barbu

Une simple commande vous aidera à y voir plus clair sur le niveau de sécurité de votre image.

Ici, par exemple, avec trivy qui est un outil très simple d'utilisation et qui va me permettre d'obtenir un rapport simple et efficace des CVE présentes sur une image :

 $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v caches:/root/.cache/ aquasec/trivy httpd
Scan de l'image httpd

Le compte-rendu vous donnera une première idée du niveau de sécurité de votre image. Malgré cette vérification, il sera également nécessaire de vérifier le(s) fichier(s) Dockerfile .

On revient donc au point évoquer plus haut et sur la nécessiste d'avoir accès facilement au(x) fichier(s) Dockerfile.

Car oui le hub docker devient une passerelle pour atteindre vos machines :

Attackers Cryptojacking Docker Images to Mine for Monero
We identified a malicious Docker Hub account named “azurenql” that contained 8 repositories, hosting 6 malicious Monero mining images.
Ashutosh ChitwadgiUnit42

Par soucis de sécurité, il est également important d'appliquer, tout simplement, les mêmes règles de sécurité à vos containers que pour votre infrastructure "classique" :

Vos machines de production sortent-elles sur internet sans firewall ? Filtrer les accès entrants ( et sortants ? ), isoler votre réseau labs du reste de votre production, etc, etc. Et n'essayez pas une nouvelle image dans un réseau non sécurisé au préalable.

Vous pourrez d'ailleurs retrouver sur le blog quelques articles afin d'hardened votre installation Docker :

Sécuriser son hôte Docker
L’utilisation de Docker pour conteneuriser vos applications peut vous apporter bien des avantages, notamment en terme de sécurité. Cependant, votre installation de Docker est-elle sécurisée ? Avez-vous déjà vérifier sa sécurité ?
Loïc FACHELa Grotte du Barbu
Sécuriser son daemon Docker
Un nouvel article sur la sécurité de Docker. Dans cet article, je ne traite pas de la sécurisation de votre applicatif conteneurisé mais bien de la sécurité de votre daemon Docker.
Loïc FACHELa Grotte du Barbu
Sécuriser l’accès à sa socket Docker...
Nous avions déjà vu ensemble comment sécuriser son daemon et son hôte Docker. Mais quand est-il de l’API disponible au travers de la socket Docker ?
Loïc FACHELa Grotte du Barbu
Docker : Hardened container avec l’option --user
Par défaut, les conteneurs Docker s’exécutent en tant que root. Ces derniers disposent forcément de nombreux privilèges ... Quand est-il de Traefik ?
Loïc FACHELa Grotte du Barbu

Enfin pour une machine de pré-production/dev, je vous conseille fortement l'utilisation du mode rootless.

Pourquoi passer aux containers Rootless ?
Effet de mode ou innovation ? Nous entendons de plus en plus parler du Rootless dans le monde des containers. Mais pourquoi ?
Loïc FACHELa Grotte du Barbu

Vous voila maintenant mieux armés pour trouver des images containers de qualité pour votre runtime favori ( Oui car ce problème n'est pas inhérent uniquement à Docker ...  ) !

Ou même encore quelques conseils utiles si vous souhaitez publier prochainement une image ...

N'hésitez pas à permettre au blog de continuer à exister et à fournir un contenu de qualité - enfin je l'espère - au travers de vos dons sur : buymeacoff.ee/lfache
Et n'hésitez pas à m'apporter des remarques ou des commentaires sur Twitter, ou ici 👇