Pourquoi la gestion des secrets compte dans Docker Swarm

Dans les flux de travail containerizzato modernes, les informations sensibles telles que les mots de passe de base de données, les jetons API, les certificats TLS et les clés de chiffrement doivent être manipulés avec une extrême prudence. Le stockage de secrets dans les variables d'environnement, les fichiers de configuration en images ou les codes d'application en dur présente de sérieux risques de sécurité : les secrets peuvent s'infiltrer dans les couches d'images, être exposés dans les journaux ou être accessibles par des conteneurs non autorisés.

La gestion des secrets est une pierre angulaire de l'orchestration des conteneurs de qualité de production. En tirant parti de la fonctionnalité de secrets intégrés de Docker, les équipes peuvent réduire la surface d'attaque, simplifier la conformité aux normes telles que PCI‐DSS ou SOC 2, et maintenir une piste d'audit claire dont les services ont accès à des secrets.

Comprendre les secrets Docker en profondeur

Qu'est-ce que les secrets Docker ?

Les secrets Docker sont des blobs chiffrés de données sensibles qui sont stockées dans le stockage interne de données de swarms (gérés par le groupe de consensus de Raft) et livrés uniquement aux conteneurs qui en ont besoin. Contrairement aux variables d'environnement, les secrets ne sont jamais visibles via ou dans l'environnement de conteneur, ils sont montés comme fichiers dans le système de fichiers de conteneur, généralement sous . Cette approche basée sur des fichiers garantit que les secrets ne sont pas accidentellement exposés par l'historique de ligne de commande, les sorties de journal ou les outils de débogage.

Comment les secrets du swarm diffèrent-ils d'autres approches

De nombreuses solutions d'orchestration reposent sur des magasins secrets externes (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et nécessitent des conteneurs de sidecar personnalisés ou des intégrations SDK. Les secrets intégrés Docker Swarm , qui fournissent un chemin intégré plus simple : pas de services supplémentaires, pas de verrouillage des fournisseurs et pas de plomberie complexe.

Principales caractéristiques des secrets de swarm Docker

  • Encryptage au repos et en transit: Les secrets sont cryptés lorsqu'ils sont stockés dans le journal de raft de swarms et lorsqu'ils sont transmis aux nœuds de manager et de travailleur.
  • Immutabilité:[ Une fois créé, un secret ne peut pas être modifié. À -update, un secret, vous devez en créer un nouveau et redéployer des services qui le référent.
  • Accès le moins cher :[ Les secrets ne sont montés que dans des conteneurs dont la définition de service inclut explicitement le secret. Aucun autre service ou conteneur autonome ne peut y accéder.
  • Aucune fuite de variables d'environnement:[ Contrairement à , les secrets ne sont jamais transmis par des variables d'environnement, réduisant ainsi le risque d'exposition accidentelle dans les processus pour enfants ou les commandes de débogage.
  • Nettoyage automatique:[ Lorsqu'un service est supprimé, les fichiers secrets associés sont supprimés du système de fichiers conteneur. Les secrets qui ne sont plus référencés par aucun service peuvent être supprimés manuellement.

Prérequis pour l'utilisation de Docker Swarm Secrets

Avant de plonger dans la mise en œuvre, assurez-vous que votre environnement répond à ces exigences :

  • Un cluster de swarm Docker (un essaim à un seul noeud suffit pour les essais, mais la production devrait utiliser plusieurs gestionnaires).
  • Docker Engine 1.13 ou plus (des secrets ont été introduits dans Docker 1.13 / API v1.25).
  • Tous les nœuds de l'essaim doivent faire partie du même groupe et être synchronisés dans le temps (recommandation NTP) pour éviter les problèmes de validation des certificats.
  • a été exécuté sur le nœud du gestionnaire, et tout noeud ouvrier a rejoint l'essaim.

Guide étape par étape pour la mise en oeuvre des secrets dans le swarm Docker

Créer un secret

Les secrets peuvent être créés à partir de fichiers ou de chaînes littérales. L'approche recommandée est d'utiliser des fichiers, car ils évitent d'exposer la valeur secrète dans l'historique du shell ou des journaux.

Création d'un secret à partir d'un fichier

echo "my-super-secure-password" > secret-file.txt
docker secret create db_password secret-file.txt

La commande retourne l'ID secret , une chaîne de caractères hexagraphiques de 25 caractères. Vous pouvez vérifier la création avec .

Création d'un secret à partir de Stdin (sans laisser de fichier sur disque)

printf "my-api-token" | docker secret create api_token -

En utilisant au lieu de , une nouvelle ligne supplémentaire est ajoutée (selon le système d'exploitation). Le trait d'union indique que le secret est lu à partir de stdin, qui est la méthode la plus sécurisée lors du script.

Création d'un secret à partir d'une valeur littéraire (non recommandée pour le script)

docker secret create my_secret "literal-value"

Cette méthode est moins sécurisée parce que la valeur littérale peut apparaître dans l'historique du shell, les journaux de vérification des commandes ou les listes de processus. Préférez la création basée sur des fichiers ou sur stdin.

Liste et inspection des secrets

Pour lister tous les secrets de l'essaim :

docker secret ls

Pour inspecter les détails (métadonnées seulement — la valeur secrète n'est jamais révélée):

docker secret inspect db_password

La sortie comprend l'ID, le nom, la date de création et les étiquettes (le cas échéant), mais jamais les données secrètes réelles.

Déployer un service qui utilise un secret

Lors de la création ou de la mise à jour d'un service, vous accordez l'accès aux secrets avec le drapeau . Le secret est monté comme un fichier à l'intérieur du conteneur à .

Créer un service avec un seul secret

docker service create \
 --name web_app \
 --secret db_password \
 --publish 80:80 \
 my_alatest

Dans le conteneur, le fichier contient la valeur secrète. L'application lit ce fichier pour obtenir le mot de passe.

Personnalisation de la cible de montage

Si vous devez monter le secret sur un autre chemin ou avec un nom de fichier différent, utilisez le drapeau avec et :

docker service create \
 --name web_app \
 --secret src=db_password,target=/etc/app/db_pass \
 my_alatest

Maintenant le secret est disponible à à l'intérieur du conteneur.

Accès aux secrets à l'intérieur du conteneur

Les demandes écrites dans n'importe quelle langue peuvent lire le secret en ouvrant et en lisant le fichier. Par exemple, dans un shell Bash à l'intérieur du conteneur:

cat /run/secrets/db_password

Dans un script Python :

with open('/run/secrets/db_password', 'r') as f:
 db_password = f.read().strip()

Les secrets ne sont jamais exposés par l'intermédiaire de l'inspection de l'environnement; le fichier est propriété de root et ne peut être lu par l'utilisateur du conteneur que si les permissions par défaut de sont appropriées. Vous pouvez outrepasser les permissions par l'intermédiaire des options , et si nécessaire (par exemple, .

Mise à jour d'un secret (Rotation)

Parce que les secrets sont immuables, mettre à jour un secret signifie en fait créer un nouveau secret et mettre à jour tous les services qui l'utilisent. Effectuer une mise à jour en continu :

  1. Créer un nouveau secret :
  2. Mettre à jour le service pour utiliser le nouveau secret et supprimer l'ancien :
  3. En option, supprimer l'ancien secret après avoir confirmé que le service fonctionne correctement:

Cette approche assure un temps d'arrêt zéro : la mise à jour en continu remplace les conteneurs un par un, chacun recevant le nouveau fichier secret.

Suppression des secrets

Les secrets qui ne sont plus référencés par aucun service peuvent être supprimés. La tentative de supprimer un secret encore en usage échouera avec une erreur.

docker secret rm db_password_v2

Vérifiez toujours qu'aucun service de fonctionnement ne dépend du secret avant la suppression. Utilisez et vérifiez les références secrètes.

Considérations avancées et pratiques exemplaires

Sécurité du chiffrement et du stockage

Docker Swarm crypte les secrets dans le journal de bord de Raft (la boutique d'état distribuée) en utilisant une clé dérivée des certificats TLS de swarms. La clé de chiffrement n'est jamais stockée sur le disque en texte simple. Cependant, les données secrètes sont déchiffrées sur les nœuds de gestionnaire lorsqu'elles sont transmises aux travailleurs. Pour protéger les secrets encore plus loin, envisagez d'utiliser un module de sécurité matérielle (HSM) ou un service de gestion des clés (KMS) si votre organisation exige la conformité FIPS‐140‐2.

Accès et segmentation des moins-privilégiers

  • N'accordez des secrets qu'aux services spécifiques qui en ont absolument besoin. Évitez d'utiliser des drapeaux wildcard ou -all secrets.
  • Secrets et services d'étiquetage pour faire respecter les limites organisationnelles (p. ex. ).
  • Utilisez des secrets distincts pour différents environnements (portage vs production) plutôt que de partager le même secret entre les piles.

Rotation et extinction

  • Automatisez la rotation secrète en utilisant des pipelines CI/CD. Créez un nouveau secret, mettez à jour le service, supprimez l'ancien secret.
  • Mettre en oeuvre un calendrier (p. ex. tous les 90 jours ou après un incident de sécurité).
  • Pour les environnements de haute sécurité, envisagez l'intégration avec HashiCorp Vault ou des outils similaires pour la gestion dynamique de la génération secrète et de la location, mais cela ajoute de la complexité.

Audit et suivi

  • Activer la logarithme de vérification de Docker (p. ex., par ] avec ou l'intégration à un système de logarithme centralisé).
  • Surveiller les événements de création, de mise à jour et de suppression secrets en utilisant Docker Events: .
  • Vérifiez les tentatives d'accès secret inattendus en vérifiant les journaux d'application ou la vérification des appels système (p. ex. .

Intégration avec les magasins secrets externes

Si les secrets intégrés Docker Swarm , sont suffisants pour de nombreux cas d'utilisation, certaines organisations exigent une gestion centralisée des secrets entre plusieurs orchestres (Kubernetes, Docker Swarm, VMs). Dans de tels scénarios, vous pouvez toujours utiliser les secrets Docker Swarm comme mécanisme de livraison tout en s'approvisionnant en valeurs réelles d'une chambre forte externe. Par exemple, un script de démarrage à l'intérieur du conteneur peut appeler l'API Vault pour récupérer un jeton (il est livré lui-même comme secret Docker) et récupérer les secrets réels à l'exécution.

Pièges courants et comment les éviter

  • Pitfall:[ Déposant par accident des secrets dans les journaux ou les messages d'erreur. Mitigation:[ Ne jamais enregistrer le contenu des fichiers secrets. Sanitize la manipulation des erreurs dans le code d'application.
  • Pitfall:[ Utiliser des secrets inexistants après la rotation. Mitigation:[ Automatiser la rotation secrète et les mises à jour de service dans votre pipeline de déploiement.
  • Pitfall: Création de secrets sur un noeud gestionnaire qui ne fait pas partie de l'essaim (p. ex., en utilisant sur un noeud autonome). Mitigation:[ Toujours exécuter des commandes de gestion secrète sur un noeud gestionnaire d'essaim.
  • Pitfall: En supposant que les secrets sont automatiquement cryptés en tout temps. Mitigation: Vérifiez que votre version Docker supporte le cryptage des secrets (1.13+) et que l'essaim est correctement initialisé. Dans les versions plus anciennes, les secrets étaient cryptés seulement en transit, pas au repos.

Exemple réel-mondial : sécuriser une connexion de base de données dans un empilement multiservices

Considérez une pile typique : un site WordPress soutenu par MySQL. Sans secrets, le mot de passe MySQL serait passé via une variable d'environnement, exposée dans . Avec les secrets de Swarm, vous créez un secret , puis déployez les deux services avec un accès à des secrets séparés.

  1. Créer un secret :
  2. Déployer le service MySQL:
  3. Déployer un service WordPress :

Les deux services lisent le mot de passe du fichier. Le mot de passe n'apparaît jamais dans les variables d'environnement, et aucun attaquant ne peut le récupérer à partir de l'API Docker sans accès au gestionnaire d'essaims.

Ressources externes et lectures complémentaires

Conclusion

En traitant les secrets comme des actifs cryptés et immuables qui ne sont montés que dans des services autorisés, vous éliminez plusieurs des vecteurs d'attaque les plus courants pour le vol de titres de compétence. Le processus de création, de déploiement, d'accès, de rotation et de suppression de secrets est simple et peut être entièrement automatisé dans le cadre d'un pipeline CI/CD. À mesure que vous adaptez vos applications conteneurisées, ces pratiques permettront de garder vos données sensibles en sécurité et vous aideront à satisfaire aux exigences de sécurité sans ajouter de frais généraux opérationnels.

Pour les équipes qui ont besoin de capacités encore plus avancées, comme la génération de secrets dynamiques, le contrôle d'accès à grain fin entre plusieurs orchestres ou l'intégration avec des modules de sécurité matérielle, Docker Secrets peut être combiné avec des systèmes de coffres externes. Mais pour la grande majorité des déploiements Docker Swarm, la fonctionnalité de secrets natifs est plus que suffisante.