‫Très
‫bien, donc une nouvelle fonctionnalité dans 1. 13 1 était un soutien complet pour les secrets.
‫Si je devais créer un slogan de ce que c'est, c'est en gros la solution la plus sécurisée pour stocker des secrets dans
‫Swarm. «Je dis
‫que c'est le plus simple, car il est intégré à Swarm, il
‫sort des sentiers battus et vous n'avez rien à faire pour l'utiliser. Tant que vous avez initialisé votre essaim et
‫votre version 1. 13 ou
‫plus récent, vous avez des secrets. Je dis que c'est sécurisé car il a été conçu
‫dès le départ pour être crypté sur disque, crypté en transit et uniquement disponible aux endroits qui lui sont nécessaires.
‫Et c'est vraiment ce dont nous avons besoin.
‫Alors qu'est-ce qu'un secret? Dans ce cas, un secret consiste à classer tout ce que vous ne
‫voulez pas en première page d'un journal. Si cela a fait la une et que vous deviez
‫le changer, c'est un secret.
‫C'est un nom d'utilisateur ou
‫un mot de passe, c'est un certificat TLS
‫ou les clés, c'est
‫une clé SSH, c'est une clé d'API Twitter, c'est une clé Amazon, c'est tout ce dont vous avez besoin pour autoriser la
‫connectivité, c'est probablement un secret et vous devriez être le protéger.
‫Jusqu'à présent, nous n'avions pas beaucoup de bonnes options pour Swarm.
‫Il existe certainement de nombreuses options telles que Vault et d'autres outils géniaux pour stocker les secrets, mais
‫elles n'étaient pas intégrées et nécessitaient une infrastructure distincte pour que vous puissiez même commencer
‫à les utiliser.
‫Nous pouvons donc stocker ici tout ce qui est une chaîne ou un binaire. 5 Mo en taille.
‫Et le plus intéressant, c’est qu’il n’est pas nécessaire de réécrire votre application
‫pour l’utiliser.
‫Il n'est pas nécessaire que votre application communique avec un service Web ailleurs pour obtenir ces informations.
‫Voyons donc comment cela fonctionne.
‫À partir de 1. 13 0 La base de données Swarm Raft est cryptée sur le disque par défaut. Si vous installez Docker et effectuez un
‫swarm init comme nous l’avons fait auparavant, il s’agit
‫d’une base de données cryptée.
‫Et quand il ferme le service, il est crypté avec les clés stockées de manière sécurisée.
‫Il est uniquement stocké sur le disque des noeuds du gestionnaire et ce sont les seuls qui disposent des
‫clés pour le déverrouiller ou le déchiffrer.
‫Cela existe déjà dans Swarm, mais les clés sont transmises aux conteneurs par
‫le biais du plan de contrôle ou des communications réseau cryptées TLS
‫entre les gestionnaires et les travailleurs. Et, cette connexion était déjà sécurisée, elle utilisait déjà l’authentification
‫TLS et l’authentification PKI mutuelle. C’était donc un excellent moyen d’utiliser ce canal existant pour transmettre ces secrets à nos conteneurs.
‫Pour les obtenir, nous les avons d'abord insérés dans la base de données Swarm à l'aide des commandes
‫Docker Secrets.
‫Ensuite, nous les affectons aux services, que nous utilisions les commandes de service elles-mêmes ou un fichier de pile
‫pour indiquer à Swarm qui est autorisé à utiliser ce secret. La clé ici est que le fait qu’il y ait un conteneur sur un
‫hôte ou un nœud et que vous avez attribué la clé à ce service ne signifie pas que d’autres conteneurs
‫peuvent y accéder.
‫Dans la mesure où cela est intégré au moteur Docker, Docker Worker conserve cette clé uniquement en mémoire et ne communique
‫que dans les conteneurs du nœud qui en a besoin.
‫Maintenant, comment ils sont présentés dans le système de fichiers au conteneur, est-ce que cela ressemble à un fichier sur le disque dur de
‫vos applications à l'intérieur du conteneur.
‫Mais ce n'est pas vraiment ça. Ils ne fonctionnent pas réellement sur le disque. Ils sont en mémoire uniquement en utilisant
‫un système de fichiers ramfs et vous les trouverez sous le répertoire / run / secrets où ce sera, par défaut, le nom que
‫vous avez donné au secret sous forme de fichier.
‫Ensuite, lorsque vous accédez simplement à ce fichier, vous verrez le secret qu'il contient.
‫Si vous considérez cela comme un magasin de
‫valeurs de clé, la clé est le nom du fichier et la valeur, son contenu.
‫Nous pouvons également configurer des alias afin que nous puissions avoir plusieurs noms pour la même clé et nous verrons comment cela entre
‫en jeu plus tard.
‫Pour le développement local, si vous utilisez un fichier de pile contenant des affectations secrètes, il fonctionnera dans
‫Docker Compose sur votre ordinateur local.
‫De nouveau, docker-compose, la ligne de commande, ne doit jamais être utilisé en production sur un serveur de production.
‫Dans ce cas en particulier, il s’agit en fait de sécurité.
‫Nous souhaitons donc que le développeur Docker ou l'utilisateur Docker installé sur leur machine puisse utiliser les fichiers
‫de la pile autant que possible.
‫Ainsi, les conteneurs que vous exécutez sur votre machine locale verront les secrets exactement comme ils le
‫feraient dans Swarm.
‫Mais nous n'avons pas Swarm sur notre machine locale à moins de l'initialiser là-bas, ce que la plupart
‫des gens ne vont pas faire.
‫Et la façon dont nous stockons les secrets se trouve dans la base de données Swarm.
‫Cela peut donc sembler évident, mais les secrets dépendent de Swarm. C'est une chose réservée à Swarm. Si vous n'avez pas Swarm,
‫vous ne pouvez pas utiliser de secrets.
‫Cependant, la commande docker-compose comporte une solution de contournement dans laquelle elle monte les secrets dans un fichier en texte
‫clair dans le conteneur local.
‫Ce n’est pas sûr, mais cela nous permet d’utiliser des secrets localement sur notre machine.
‫Ce n'est tout simplement pas quelque chose que vous voudriez utiliser en production, c'est pourquoi nous avons le magasin sécurisé
‫de Swarm.