Gérer la sécurité swarm avec l'infrastructure à clés publiques (PKI)

Table des matières

Le système d'infrastructure à clés publiques (PKI) du mode Swarm intégré dans Docker rend simple le déploiement sécurisé d'un système d'orchestration de conteneurs. Les nœuds dans un swarm utilisent le Transport Layer Security (TLS) mutuel pour authentifier, autoriser, et chiffrer les communications avec d'autres nœuds dans le swarm.

Lorsque vous créez un swarm en exécutant docker swarm init, Docker se désigne lui-même comme un nœud gestionnaire. Par défaut, le nœud gestionnaire génère une nouvelle Autorité de Certification (CA) racine avec une paire de clés, qui sont utilisées pour sécuriser les communications avec d'autres nœuds qui rejoignent le swarm. Si vous préférez, vous pouvez spécifier votre propre CA racine générée externement, en utilisant le drapeau --external-ca de la commande docker swarm init.

Le nœud gestionnaire génère également deux jetons à utiliser lorsque vous ajoutez des nœuds supplémentaires au swarm : un jeton travailleur et un jeton gestionnaire. Chaque jeton inclut le condensé du certificat de la CA racine et un secret généré aléatoirement. Quand un nœud rejoint le swarm, le nœud qui rejoint utilise le condensé pour valider le certificat de la CA racine du gestionnaire distant. Le gestionnaire distant utilise le secret pour s'assurer que le nœud qui rejoint est un nœud approuvé.

Chaque fois qu'un nouveau nœud rejoint le swarm, le gestionnaire émet un certificat au nœud. Le certificat contient un ID de nœud généré aléatoirement pour identifier le nœud sous le nom commun (CN) du certificat et le rôle sous l'unité organisationnelle (OU). L'ID de nœud sert d'identité de nœud cryptographiquement sécurisée pour la durée de vie du nœud dans le swarm actuel.

Le diagramme ci-dessous illustre comment les nœuds gestionnaires et les nœuds travailleurs chiffrent les communications en utilisant un minimum de TLS 1.2.

L'exemple ci-dessous montre les informations d'un certificat d'un nœud travailleur :

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3b:1c:06:91:73:fb:16:ff:69:c3:f7:a2:fe:96:c1:73:e2:80:97:3b
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=swarm-ca
        Validity
            Not Before: Aug 30 02:39:00 2016 GMT
            Not After : Nov 28 03:39:00 2016 GMT
        Subject: O=ec2adilxf4ngv7ev8fwsi61i7, OU=swarm-worker, CN=dw02poa4vqvzxi5c10gm4pq2g
...snip...

Par défaut, chaque nœud dans le swarm renouvelle son certificat tous les trois mois. Vous pouvez configurer cet intervalle en exécutant la commande docker swarm update --cert-expiry <PÉRIODE DE TEMPS>. La valeur minimale de rotation est 1 heure. Référez-vous à la référence CLI docker swarm update pour les détails.

Rotation du certificat CA

Note

Mirantis Kubernetes Engine (MKE), anciennement connu sous le nom de Docker UCP, fournit un service de gestion de certificats externe pour le swarm. Si vous exécutez swarm sur MKE, vous ne devriez pas effectuer manuellement la rotation des certificats CA. À la place, contactez le support Mirantis si vous avez besoin de faire tourner un certificat.

Dans le cas où une clé CA de cluster ou un nœud gestionnaire est compromis, vous pouvez faire tourner la CA racine du swarm pour qu'aucun des nœuds ne fasse plus confiance aux certificats signés par l'ancienne CA racine.

Exécutez docker swarm ca --rotate pour générer un nouveau certificat et une nouvelle clé CA. Si vous préférez, vous pouvez passer les drapeaux --ca-cert et --external-ca pour spécifier le certificat racine et pour utiliser une CA racine externe au swarm. Alternativement, vous pouvez passer les drapeaux --ca-cert et --ca-key pour spécifier le certificat exact et la clé que vous aimeriez que le swarm utilise.

Lorsque vous émettez la commande docker swarm ca --rotate, les choses suivantes arrivent en séquence :

Docker génère un certificat à signature croisée. Cela signifie qu'une version du nouveau certificat CA racine est signée avec l'ancien certificat CA racine. Ce certificat à signature croisée est utilisé comme certificat intermédiaire pour tous les nouveaux certificats de nœud. Cela assure que les nœuds qui font encore confiance à l'ancienne CA racine peuvent toujours valider un certificat signé par la nouvelle CA.
Docker dit également à tous les nœuds de renouveler immédiatement leurs certificats TLS. Ce processus peut prendre plusieurs minutes, selon le nombre de nœuds dans le swarm.
Après que chaque nœud dans le swarm ait un nouveau certificat TLS signé par la nouvelle CA, Docker oublie l'ancien certificat CA et le matériel de clé, et dit à tous les nœuds de faire confiance uniquement au nouveau certificat CA.

Cela cause également un changement dans les jetons de jointure du swarm. Les jetons de jointure précédents ne sont plus valides.

À partir de ce point, tous les nouveaux certificats de nœud émis sont signés avec la nouvelle CA racine, et ne contiennent aucun intermédiaire.

En savoir plus

Lisez comment les nœuds fonctionnent.
Apprenez comment les services du mode Swarm fonctionnent.