Protéger les secrets Docker (même si vous n’utilisez pas Kubernetes)
Marcelo Oliveira
24 août 2022
0 minutes de lectureLes systèmes distribués basés sur des conteneurs assemblent des applications, des ressources, des services, des bases de données et d’autres artefacts. Pour fonctionner correctement, ces composants ont souvent besoin d’informations sensibles, comme des clés utilisateur, des mots de passe, des clés API et des certificats.
La gestion des secrets est essentielle pour traiter correctement les informations sensibles. Les déploiements Kubernetes utilisent souvent le type de ressource Secrets intégré et les contrôles RBAC associés. Mais que faire si vous ne déployez pas sur Kubernetes ? De nombreuses organisations n’ont tout simplement pas besoin de la puissance de Kubernetes ou ne souhaitent pas assumer la complexité liée à son exploitation, mais doivent tout de même éviter les risques de fuite de données ou de perte de mots de passe. Heureusement, l’orchestrateur Swarm intégré à Docker apporte une solution.
Cet article explique comment gérer les secrets dans Docker, en présentant les bonnes pratiques et les risques potentiels liés à leur utilisation. Il propose également un exercice simple pour créer et répertorier des secrets Docker, ainsi que pour les ajouter à un service et les en supprimer. Il est supposé que le lecteur possède des connaissances de base sur le moteur d’exécution de conteneurs Docker et son orchestrateur Swarm.
Sécuriser les secrets Docker
Chaque fois que vous transmettez des secrets ou des données sensibles au sein de votre organisation, vous risquez une fuite de données ou la perte de mots de passe. Lorsque vous travaillez sur un projet Docker qui nécessite de manipuler des informations sensibles, comme des mots de passe, des clés privées, des jetons et des clés API, vous devez définir une méthode sûre pour stocker ces secrets et les transmettre aux conteneurs.
L’une des pires approches consiste à laisser des données sensibles dans le code source. Outre les problèmes de sécurité, inscrire des secrets en dur dans votre code signifie que vous devez reconstruire l’image lorsque les secrets changent.
Une autre mauvaise pratique consiste à gérer « manuellement » des informations importantes, comme les mots de passe et les clés SSH, en laissant les informations secrètes sur le disque local. N’oubliez pas que des programmes malveillants ou non autorisés peuvent également lire vos fichiers.
Les développeurs ont souvent recours aux variables d’environnement pour stocker des données sensibles. Cette méthode peut convenir à certains cas, mais elle est déconseillée pour les conteneurs Docker. Les variables d’environnement sont encore moins sécurisées que les fichiers. Elles présentent davantage de vulnérabilités, notamment :
La commande docker inspect
Fichiers journaux d’événements
Par exemple, une application peut vider le context dans un journal dans le cadre du traitement d’une exception. Le journal peut alors contenir les valeurs sensibles des variables d’environnement.
Un gestionnaire de secrets est une bien meilleure solution que les options précédentes : il fournit un emplacement centralisé pour gérer les secrets dans Docker Swarm. Il vous aide à protéger l’accès à vos applications, services et ressources informatiques en proposant un service pratique pour stocker, gérer et récupérer des secrets. Il peut s’agir d’identifiants de base de données pour les API, de clés, de mots de passe, de clés privées SSH, de certificats SSL et d’autres données sensibles dont une application a besoin à l’exécution.
Comment Docker gère les secrets
Le schéma ci-dessus montre que Docker utilise Raft, un algorithme de consensus permettant de gérer un journal répliqué dans un système distribué, afin de garantir la cohérence de vos données dans l’ensemble du cluster Swarm et de tous les services qui y sont exécutés. L’algorithme Raft transmet systématiquement les secrets sous forme chiffrée à tous les nœuds managers.
Le schéma montre également les nœuds workers, des instances de Docker Engine dédiées à l’exécution de conteneurs. Les nœuds managers distribuent les secrets aux conteneurs associés au service auquel la clé a été attribuée.
Les secrets Docker fonctionnent comme un coffre-fort dans lequel vous pouvez placer des données sensibles. Vous ne pouvez les utiliser que si vous possédez la clé du coffre-fort, que vous devez obtenir auprès des nœuds de service auxquels vous avez attribué cette clé.
Le service de gestion des secrets Docker fait partie de sa pile d’orchestration de conteneurs et automatise la sécurisation de ces données.
Dans les services Docker Swarm, les secrets sont chiffrés au repos et en transit.
Les secrets Docker peuvent être gérés de manière centralisée et transmis de façon sécurisée aux conteneurs qui doivent y accéder. Chaque secret n’est accessible qu’aux services auxquels cet accès a été explicitement accordé, et uniquement pendant l’exécution du service.
Lorsqu’un service accède à des secrets, il les déchiffre et les partage avec le conteneur dans un système de fichiers en mémoire. Lorsque la tâche du conteneur s’arrête, les secrets déchiffrés disponibles sont immédiatement détachés et effacés de la mémoire du nœud.
Gérer les secrets avec la CLI Docker
Les fonctionnalités intégrées de Docker permettent aux utilisateurs de saisir des secrets et de contrôler précisément les services autorisés à y accéder, ainsi que les circonstances dans lesquelles ils peuvent les utiliser.
Cet exercice simple crée un service MySQL avec un mot de passe root et ajoute les identifiants sous forme de secrets.
Comme les secrets Docker sont uniquement disponibles pour les services Swarm, vous devez configurer un Docker Swarm pour les utiliser. Mais commencez par vérifier que vous avez installé la ligne de commande Docker (Docker CLI). Si ce n’est pas déjà fait, initialisez le cluster ou rejoignez-le :
Ajoutez maintenant un secret à Docker.
Créez un fichier texte à l’emplacement où vous souhaitez stocker votre secret. La commande suivante crée le fichier password.txt contenant la chaîne this-is-a-mysql-password.
Utilisez maintenant la commande docker secret create pour créer un secret à partir du fichier créé à l’étape précédente :
Notez que la chaîne l1m5jvgcox1l96i6bjbz4dvnt ci-dessus correspond à l’ID du secret, et non au secret lui-même. Elle sera donc probablement différente dans votre environnement.
Voyons maintenant une autre façon d’utiliser la commande docker secret create. Ici, omettez le nom du fichier en indiquant un tiret (-) comme dernier argument, qui représente le fichier :
Cette commande génère une sortie similaire à celle ci-dessous :
Cette méthode ne précise pas le fichier à partir duquel lire le secret ; la commande docker secret create lit alors l’entrée standard pour créer le secret another-mysql-password.
Répertorier les secrets Docker
Pour répertorier les secrets disponibles dans Docker Swarm, exécutez la commande docker secret ls :
La sortie affiche les secrets que vous avez créés dans Docker Swarm :
Créer un service avec des secrets
Vous pouvez créer un service en utilisant l’un des secrets créés précédemment.
Créez le service mysql-service et utilisez l’option --secret pour autoriser le conteneur à accéder au secret another-mysql-secret :
Ajouter des secrets à un service existant ou en supprimer
Vous pouvez supprimer un secret d’un service existant :
Vous pouvez aussi ajouter un secret à un service en cours d’exécution :
Lorsque vous associez un secret à un service, Docker crée un fichier texte portant le nom de votre secret. Ce fichier contient une chaîne représentant le secret et se trouve par défaut dans le répertoire /run/secrets, monté dans un système de fichiers temporaire (TMPFS) au sein du conteneur. Dans notre cas, le fichier se trouve à l’emplacement /run/secrets/mysql-password-secret. Dès sa création, le secret est disponible dans tous les conteneurs de ce service.
Solutions externes de gestion des secrets
Les secrets Docker constituent une excellente solution, mais vous devriez également envisager de confier cette tâche à des solutions tierces de stockage des secrets. C’est particulièrement pertinent si votre organisation dispose déjà de compétences et d’investissements dans une plateforme donnée.
Par exemple, si votre entreprise utilise déjà Hashicorp Vault et que vos applications y sont intégrées, rien ne justifie vraiment de passer aux secrets Docker — ni, d’ailleurs, aux secrets Kubernetes — simplement parce qu’ils sont fournis par la plateforme. Tirez parti des processus, des bibliothèques et de l’expertise déjà en place autour de cette solution dans vos services.
Parmi les solutions de gestion des secrets les plus populaires, citons :
Solutions des fournisseurs de cloud (AWS Secrets Manager, GCP Secret Manager, etc.)
Protégez vos secrets
Cet article a présenté les secrets et leur gestion dans le contexte de Docker Swarm, et expliqué comment Docker les gère. Il a montré qu’un gestionnaire de secrets est une bien meilleure solution que d’inscrire des données sensibles en dur, d’utiliser des variables d’environnement ou de gérer les secrets manuellement.
La sécurité des données est l’un des piliers d’une gouvernance d’entreprise efficace. Grâce à ses commandes CLI et à son architecture en mémoire, qui permet un déploiement précis des données secrètes, Docker fournit des outils de gestion des secrets fiables pour vous aider à mettre en œuvre correctement la sécurité des informations de votre organisation.
Protéger vos secrets des regards indiscrets est une première étape pour créer des conteneurs sécurisés. Snyk Code vous aide à repérer les secrets inscrits en dur, tandis que Snyk Container et Snyk Open Source vous orientent vers les images de base et les packages les plus sécurisés pour vos conteneurs. Et lorsque vous serez prêt à passer en production, Snyk IaC vous aidera à réduire les risques avant et après le déploiement. Commencez gratuitement dès aujourd’hui pour détecter et corriger automatiquement les vulnérabilités dans votre code, vos dépendances open source, vos conteneurs et votre infrastructure cloud.
La sécurité des conteneurs, pensée pour les développeurs
Snyk détecte et corrige automatiquement les vulnérabilités dans les images de conteneurs et les workloads Kubernetes.