Vous pensiez que vos secrets étaient en sécurité dans vos images Docker ? Détrompez-vous ! Une étude de l’Université d’Aix-la-Chapelle a révélé que près de 10% des images publiques sur DockerHub contenait des secrets (donc des identifiants, des clés API, des mots de passe, des endpoints sensibles…Etc).

Ça fait froid dans le dos.

On parle de plus de 50 000 clés d’API et d’identifiants accessibles publiquement. Et ce n’est que la partie émergée de l’iceberg puisque les chercheurs de Redhunt Labs ont aussi trouvé plus de 46 000 Dockerfiles exposant des infos sensibles. Bref, c’est la fête du slip côté sécurité !

Mais comment ces secrets se retrouvent-ils à fuiter comme une passoire ? Et bien c’est souvent, c’est à cause d’opérations de fichiers trop permissives, de secrets mis en dur dans les Dockerfiles…etc

Par exemple, beaucoup de tutos et même la doc officielle de Docker suggèrent d’utiliser COPY . . pour copier tout le répertoire courant dans l’image. Sauf que ça inclut aussi les fichiers sensibles comme .env ou l’historique Git. Pas top pour la confidentialité.

Et même si vous supprimez ces fichiers sensibles après le COPY, ils restent présents dans les couches précédentes de l’image. Un attaquant pourra donc toujours y accéder. Merci les layers 🙂

Autre coup classique : mettre directement les secrets dans le Dockerfile ou les passer en argument au build. Là encore, c’est cadeau pour les hackers. Un simple docker history --no-trunc et hop, vos secrets sont à nu.

Heureusement, il existe des solutions pour sécuriser tout ça. Par exemple, les builds multi-stages permettent d’isoler les secrets dans une étape intermédiaire qui ne sera pas conservée dans l’image finale. Et depuis peu, BuildKit propose une option --secret pour injecter les secrets sans les stocker dans l’image, mais attention aux pièges ! Si votre app log le secret qu’elle utilise, il finira quand même dans l’image. Les builds multi-stages restent donc plus safe de ce côté là.

Bref, vous l’aurez compris, la gestion des secrets dans Docker, c’est pas de la tarte mais en suivant les bonnes pratiques, vous pourrez limiter les risques.

Bref, pensez builds multi-stages, utilisez .dockerignore, oubliez les secrets en dur et n’abusez pas des arguments de build. Et surtout, ayez le réflexe d’auditer vos images avec des outils comme TruffleHog. Parce qu’un secret qui fuite, c’est votre réputation qui coule.

Si vous êtes devop, vous savez qu’il est essentiel de savoir surveiller et déboguer les applications en temps réel.

Mais le faire n’est pas si simple, surtout si celles-ci tournent dans des conteneurs Docker. C’est là qu’intervient l’outil libre Dozzle !

Grâce à une interface intuitive et des fonctionnalités d’analyse temps réel et de filtrage, les développeurs et les administrateurs système que vous êtes pourront facilement accéder aux journaux générés par leurs conteneurs Docker.

Avec Dozzle, les utilisateurs peuvent bénéficier d’un affichage des logs en temps réel sans avoir besoin de rafraîchir la page et l’outil prend en charge les journaux JSON avec une coloration intelligente, ce qui en facilite la lecture et la compréhension. L’installation et la configuration de Dozzle sont relativement simples et rapides. L’outil peut être installé localement ou utilisé pour se connecter à des hôtes distants via tcp:// et tls.

Le moyen le plus simple d’installer Dozzle est d’utiliser la commande Docker CLI et de monter le fichier docker.sock. Ce fichier se trouve généralement dans le répertoire /var/run/docker.sock. Vous devez également spécifier le port d’accès à l’interface de Dozzle. Par défaut, Dozzle écoute sur le port 8080, mais vous pouvez modifier le port externe en utilisant l’option -p.

Voici la commande à utiliser :

docker run --detach --volume=/var/run/docker.sock:/var/run/docker.sock -p 8080:8080 amir20/dozzle

Docker Compose permet de configurer Dozzle plus facilement au sein d’un projet existant.

Voici un exemple de fichier docker-compose.yml pour Dozzle :

version: "3"
services:
  dozzle:
    container_name: dozzle
    image: amir20/dozzle:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9999:8080

Ensuite, pour lancer Dozzle avec Docker Compose, enregistrez le fichier docker-compose.yml dans votre projet et exécutez la commande suivante dans votre terminal :

docker-compose up -d

Quelle que soit la méthode choisie, une fois Dozzle lancé, vous pourrez alors accéder à son interface web pour visualiser les journaux de vos conteneurs Docker.

Amusez-vous bien et bon debugging à tous !