⚠️ Traduction non officielle - Cette documentation est une traduction communautaire non officielle de Docker.

Gérer les clés pour la confiance de contenu

Table des matières

La confiance pour une étiquette d'image est gérée grâce à l'utilisation de clés. La confiance de contenu de Docker utilise cinq types différents de clés :

Clé Description
clé racine Racine de la confiance de contenu pour une étiquette d'image. Lorsque la confiance de contenu est activée, vous créez la clé racine une fois. Aussi connue sous le nom de clé hors ligne, car elle devrait être gardée hors ligne.
targets Cette clé vous permet de signer des étiquettes d'image, de gérer les délégations incluant les clés déléguées ou les chemins de délégation autorisés. Aussi connue sous le nom de clé de dépôt, puisque cette clé détermine quelles étiquettes peuvent être signées dans un dépôt d'image.
snapshot Cette clé signe la collection actuelle d'étiquettes d'image, empêchant les attaques de mélange et d'assortiment.
timestamp Cette clé permet aux dépôts d'images Docker d'avoir des garanties de sécurité de fraîcheur sans nécessiter de rafraîchissements périodiques de contenu côté client.
délégation Les clés de délégation sont des clés d'étiquetage optionnelles et vous permettent de déléguer la signature d'étiquettes d'image à d'autres éditeurs sans avoir à partager votre clé targets.

Lors d'un docker push avec Content Trust activé pour la première fois, les clés root, targets, snapshot, et timestamp sont générées automatiquement pour le dépôt d'image :

  • Les clés root et targets sont générées et stockées localement côté client.

  • Les clés timestamp et snapshot sont générées en sécurité et stockées dans un serveur de signature qui est déployé aux côtés du registre Docker. Ces clés sont générées dans un service backend qui n'est pas directement exposé à internet et sont chiffrées au repos. Utilisez la CLI Notary pour gérer votre clé snapshot localement.

Les clés de délégation sont optionnelles, et ne sont pas générées dans le cadre du flux de travail docker normal. Elles doivent être générées manuellement et ajoutées au dépôt.

Choisir une phrase de passe

Les phrases de passe que vous choisissez pour la clé racine et votre clé de dépôt devraient être générées aléatoirement et stockées dans un gestionnaire de mots de passe. Avoir la clé de dépôt permet aux utilisateurs de signer des étiquettes d'image sur un dépôt. Les phrases de passe sont utilisées pour chiffrer vos clés au repos et s'assurer qu'un ordinateur portable perdu ou une sauvegarde non intentionnelle ne mette pas le matériel de clé privée en danger.

Sauvegarder vos clés

Toutes les clés de confiance Docker sont stockées chiffrées en utilisant la phrase de passe que vous fournissez à la création. Même ainsi, vous devriez toujours faire attention à l'endroit où vous les sauvegardez. Une bonne pratique est de créer deux clés USB chiffrées.

Warning

Il est très important que vous sauvegardiez vos clés dans un endroit sûr et sécurisé. La perte de la clé de dépôt est récupérable, mais la perte de la clé racine ne l'est pas.

Le client Docker stocke les clés dans le répertoire ~/.docker/trust/private. Avant de les sauvegarder, vous devriez les archiver avec tar :

$ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022

Stockage matériel et signature

Docker Content Trust peut stocker et signer avec des clés racines d'un Yubikey 4. Le Yubikey est priorisé par rapport aux clés stockées dans le système de fichiers. Lorsque vous initialisez un nouveau dépôt avec la confiance de contenu, Docker Engine recherche une clé racine localement. Si une clé n'est pas trouvée et que le Yubikey 4 existe, Docker Engine crée une clé racine dans le Yubikey 4. Consultez la documentation Notary pour plus de détails.

Avant Docker Engine 1.11, cette fonctionnalité était seulement dans la branche expérimentale.

Perte de clé

Warning

Si un éditeur perd des clés, cela signifie perdre la capacité de signer des images pour les dépôts en question. Si vous perdez une clé, envoyez un email au Support Docker Hub. Comme rappel, la perte d'une clé racine n'est pas récupérable.

Cette perte nécessite également une intervention manuelle de chaque consommateur qui a utilisé une étiquette signée de ce dépôt avant la perte.
Les consommateurs d'images obtiennent l'erreur suivante pour le contenu précédemment téléchargé depuis le(s) dépôt(s) affecté(s) :

Warning: potential malicious behavior - trust data has insufficient signatures for remote repository docker.io/my/image: valid signatures did not meet threshold

Pour corriger cela, ils doivent télécharger une nouvelle étiquette d'image qui est signée avec la nouvelle clé.

Informations connexes