La gestion sécurisée des secrets est un aspect important de la sécurité des conteneurs. Si vous injectez des mots de passe et des clés API en tant que variables d'environnement, vous risquez d'exposer involontairement des informations. Les variables shell sont souvent enregistrées, transmises aux processus enfants ou divulguées aux services de rapport d'erreurs à votre insu.
L'injection de valeurs en tant que secrets dédiés atténue ces risques. Docker a un support intégré pour la gestion sécurisée des secrets auquel vous pouvez vous connecter avec Docker Compose. L'accès aux secrets est accordé service par service.
Comment fonctionnent les secrets ?
La CLI Docker a un lot de secrets commandes de gestion, mais celles-ci ne fonctionnent qu'avec les clusters Swarm. Vous ne pouvez pas ajouter de secrets à des conteneurs autonomes en utilisant uniquement la CLI Docker.
Docker Compose a ajouté “faux” secrets pour apporter ces fonctionnalités aux charges de travail sans cluster. L'implémentation de Compose fonctionne de manière similaire aux fonctionnalités de Docker Swarm et fonctionne avec n'importe quel fichier Compose.
Les secrets sont créés sous forme de fichiers texte normaux qui sont montés par liaison dans vos conteneurs. Votre application accède à la valeur du secret en lisant le contenu du fichier. Ce modèle permet aux valeurs de rester inertes jusqu'à ce qu'elles soient explicitement utilisées dans votre conteneur, contrairement aux variables d'environnement visibles en permanence.
Définition de secrets dans des fichiers de composition
L'obtention d'un secret dans un conteneur est un processus en deux étapes. Vous devez d'abord définir le secret, en utilisant le champ secrets de niveau supérieur dans votre fichier Compose. Ensuite, vous mettez à jour vos définitions de service pour référencer les secrets dont elles ont besoin.
Publicité
Voici un exemple qui utilise des secrets pour fournir en toute sécurité un mot de passe à un service :
version: “3” services: app: image: example-app:latest secrets: – db_password secrets: db_password: file: ./db_password.txt
La valeur du secret’sera lue depuis votre répertoire de travail’ ;s fichier db_password.txt lorsque vous exécutez docker-compose up. Compose montera le fichier dans /run/secrets/db_password dans le conteneur. Votre application peut accéder au mot de passe de la base de données en lisant le contenu du fichier secret.
Utilisation des secrets Docker existants
Au-delà des secrets basés sur des fichiers, Compose vous permet également de référencer des secrets Docker Swarm existants. Si vous utilisez ce mécanisme, vous devez créer les secrets dans Docker avant d'exécuter docker-compose up. L'espace de commande docker secrets ne fonctionnera que lorsque votre point de terminaison Docker actif est un nœud de gestionnaire Swarm.
Créez le secret à l'aide de la CLI Docker :
# prendre la valeur de l'entrée standard echo P@55w0rd | docker secret créer db_password – OU # prend la valeur d'un fichier docker secret create db_password ./db_password.txt
Mettez maintenant à jour votre fichier Docker Compose pour référencer le secret :
version : “3” services : app : image : example-app:latest secrets : – db_password secrets : db_password : external : true
Définition du secret’ ;s Le champ externe indique à Compose de rechercher sa valeur à partir de vos secrets Docker existants. La pile échouera avec une erreur si vous essayez de la démarrer avant que le secret n'existe.
Syntaxe du secret étendu
Compose prend en charge une syntaxe de secrets plus longue si vous avez besoin d'un contrôle plus granulaire sur le processus d'injection. Le passage à cette syntaxe vous permet de personnaliser les autorisations de fichier et de modifier le nom monté du secret.
Cinq champs facultatifs sont disponibles :
- source – Le nom du secret à référencer – cela doit être l'une des valeurs définies dans la section des secrets de votre fichier de composition.
- cible – Nom de fichier à utiliser lorsque le secret est monté dans le conteneur.
- uid– UID à définir sur le fichier secret monté. La valeur par défaut est 0.
- gid – GID à définir sur le fichier secret monté. La valeur par défaut est 0.
- mode – Autorisations du système de fichiers à appliquer au fichier secret monté, exprimées en notation octale. La valeur par défaut est 0444. Attention, les fichiers secrets ne sont jamais accessibles en écriture car ils sont toujours montés dans le système de fichiers temporaire d'un conteneur.
Publicité
Voici’s un exemple modifié qui renomme le fichier secret monté et change ses permissions :
version : “3” services : app : image : example-app:latest secrets : – source : db_password cible : database_password_secret mode : 0440 secrets : db_password : external : true
La syntaxe simple est généralement suffisante pour la plupart des déploiements. Si vous avez des exigences plus spécifiques, la version étendue devrait vous donner le contrôle dont vous avez besoin. Les références secrètes individuelles peuvent mélanger et faire correspondre les deux syntaxes dans le même fichier Compose.
Secrets et paternité des images
De nombreuses images Docker populaires de la communauté prennent désormais en charge les secrets au lieu des variables d'environnement. En tant qu'auteur d'images, offrir des secrets est une approche exemplaire pour protéger vos utilisateurs’ données.
Vous pouvez prendre en charge les deux mécanismes en permettant aux variables d'environnement d'être définies sur un chemin de fichier. Si votre image nécessite une connexion à une base de données, laissez les utilisateurs définir la variable d'environnement DB_PASSWORD sur P@55w0rd ou /run/secrets/db_password. Votre conteneur doit vérifier si la valeur de la variable référence un fichier valide ; si c'est le cas, supprimez-le et lisez la valeur finale dans le fichier.
Ce modèle donne aux utilisateurs la possibilité de choisir le mécanisme le plus approprié pour leur déploiement. N'oubliez pas que tous les utilisateurs ne pourront pas adopter des secrets – si Swarm et Compose sont tous deux indisponibles, ils n'auront aucun moyen de fournir leurs valeurs.
Conclusion
L'utilisation de secrets au lieu de variables d'environnement régulières réduit les risques de divulgation involontaire d'informations. Imaginez le pire des cas où un conteneur envoie ses variables d'environnement à un service de journalisation tiers compromis. Les attaquants disposent désormais de votre mot de passe de base de données et de vos clés API.
Publicité
En limitant les données secrètes à l'accès au système de fichiers, les valeurs ne peuvent pas être lues par inadvertance car elles ne sont pas une caractéristique perpétuelle de votre environnement. N'oubliez pas que les fichiers secrets comportent cependant leurs propres risques. Vous pourriez être tenté de les valider dans le contrôle des sources, ce qui signifierait que toute personne ayant accès à votre référentiel pourrait lire leurs valeurs.
Les secrets doivent être “secret” tout au long du cycle de vie de votre conteneur. Pour les déploiements en production, il est généralement préférable d'automatiser les builds avec un système CI. Définissez vos secrets dans les paramètres de pipeline de votre fournisseur CI, puis utilisez votre script de génération pour les écrire dans des fichiers auxquels Compose peut accéder. Cela garantit que vous seul avez accès aux valeurs réelles, via l'interface de votre outil CI.