La gestion des secrets sécurisés 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 transmises aux services de rapport d'erreurs à votre insu.
L'injection de valeurs sous forme de secrets dédiés atténue ces risques. Docker a une prise en charge intégrée pour la gestion sécurisée des secrets à laquelle vous pouvez vous connecter avec Docker Compose. L'accès aux secrets est accordé service par service.
Comment fonctionnent les secrets ?
La CLI Docker dispose d'un lot de commandes de gestion secrètes, mais celles-ci ne fonctionnent qu'avec les clusters Swarm. Vous ne pouvez pas ajouter de secrets à des conteneurs autonomes à l'aide de la CLI Docker seule.
Docker Compose a ajouté de « faux » secrets pour apporter ces fonctionnalités aux charges de travail sans cluster. L'implémentation de Compose fonctionne de la même manière que les 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 en 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éfinir les secrets dans les fichiers Compose
Obtenir un secret dans un conteneur est un processus en deux étapes. Vous devez d'abord définir le secret, en utilisant les secrets de niveau supérieur champ dans votre fichier Compose. Ensuite, vous mettez à jour vos définitions de service pour référencer les secrets dont ils ont besoin.
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 à partir du db_password.txt de votre répertoire de travail fichier lorsque vous exécutez docker-compose up . Compose montera le fichier dans /run/secrets/db_password à l'intérieur du 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 les secrets Docker Swarm existants. Si vous utilisez ce mécanisme, vous devez créer les secrets dans Docker avant vous exécutez docker-compose up . Les docker secrets L'espace de commande 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 :
# take value from standard input echo P@55w0rd | docker secret create db_password - OR # take value from a file docker secret create db_password ./db_password.txt
Maintenant, mettez à 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 external indique à Compose de tirer sa valeur 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 secrète étendue
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 fichiers et de modifier le nom monté du secret.
Cinq champs optionnels sont disponibles :
source– Le nom du secret à référencer – il doit s'agir de l'une des valeurs définies dans lessecretsde votre fichier Compose section.target– 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.
Voici un exemple modifié qui renomme le fichier secret monté et modifie ses autorisations :
version: "3"
services:
app:
image: example-app:latest
secrets:
- source: db_password
target: 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 communautaires populaires prennent désormais en charge les secrets au lieu des variables d'environnement. En tant qu'auteur d'images, offrir des secrets est une bonne pratique pour protéger les données de vos utilisateurs.
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 à la base de données, laissez les utilisateurs définir le DB_PASSWORD variable d'environnement soit P@55w0rd ou /run/secrets/db_password . Votre conteneur doit vérifier si la valeur de la variable fait référence à un fichier valide ; si c'est le cas, jetez-le et lisez la valeur finale du fichier.
Ce modèle donne aux utilisateurs la flexibilité 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 ne sont pas disponibles, 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 scénario dans lequel un conteneur envoie ses variables d'environnement à un service de journalisation tiers compromis. Les attaquants ont maintenant votre mot de passe de base de données et vos clés API.
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 leurs propres risques. Vous pourriez être tenté de les valider dans le contrôle de code source, ce qui signifierait que toute personne ayant accès à votre référentiel pourrait lire leurs valeurs.
Les secrets doivent rester "secrets" tout au long du cycle de vie de votre conteneur. Pour les déploiements de 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.