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

Confiance de contenu dans Docker

Table des matières

Lors du transfert de données entre systèmes en réseau, la confiance est une préoccupation centrale. En particulier, lors de la communication sur un support non fiable tel qu'internet, il est critique d'assurer l'intégrité et l'éditeur de toutes les données sur lesquelles un système opère. Vous utilisez Docker Engine pour pousser et tirer des images (données) vers un registre public ou privé. La confiance de contenu vous donne la capacité de vérifier à la fois l'intégrité et l'éditeur de toutes les données reçues d'un registre sur n'importe quel canal.

À propos de Docker Content Trust (DCT)

Docker Content Trust (DCT) fournit la capacité d'utiliser des signatures numériques pour les données envoyées et reçues des registres Docker distants. Ces signatures permettent la vérification côté client ou à l'exécution de l'intégrité et de l'éditeur d'étiquettes d'image spécifiques.

Grâce à DCT, les éditeurs d'images peuvent signer leurs images et les consommateurs d'images peuvent s'assurer que les images qu'ils tirent sont signées. Les éditeurs peuvent être des individus ou des organisations signant manuellement leur contenu ou des chaînes d'approvisionnement logiciel automatisées signant le contenu dans le cadre de leur processus de publication.

Étiquettes d'image et DCT

Un enregistrement d'image individuel a l'identifiant suivant :

[REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]

Un REPOSITORY d'image particulier peut avoir plusieurs étiquettes. Par exemple, latest et 3.1.2 sont toutes deux des étiquettes sur l'image mongo. Un éditeur d'image peut construire une image et une combinaison d'étiquette plusieurs fois en changeant l'image à chaque construction.

DCT est associé à la portion TAG d'une image. Chaque dépôt d'image a un ensemble de clés que les éditeurs d'images utilisent pour signer une étiquette d'image. Les éditeurs d'images ont la discrétion sur quelles étiquettes ils signent.

Un dépôt d'image peut contenir une image avec une étiquette qui est signée et une autre étiquette qui ne l'est pas. Par exemple, considérez le dépôt d'image Mongo . L'étiquette latest pourrait être non signée tandis que l'étiquette 3.1.6 pourrait être signée. Il est de la responsabilité de l'éditeur d'image de décider si une étiquette d'image est signée ou non. Dans cette représentation, certaines étiquettes d'image sont signées, d'autres ne le sont pas :

Étiquettes signées

Les éditeurs peuvent choisir de signer une étiquette spécifique ou non. En conséquence, le contenu d'une étiquette non signée et celui d'une étiquette signée avec le même nom peuvent ne pas correspondre. Par exemple, un éditeur peut pousser une image étiquetée someimage:latest et la signer. Plus tard, le même éditeur peut pousser une image someimage:latest non signée. Cette seconde poussée remplace la dernière étiquette non signée latest mais n'affecte pas la version latest signée. La capacité de choisir quelles étiquettes ils peuvent signer, permet aux éditeurs d'itérer sur la version non signée d'une image avant de la signer officiellement.

Les consommateurs d'images peuvent activer DCT pour s'assurer que les images qu'ils utilisent ont été signées. Si un consommateur active DCT, ils ne peuvent que tirer, exécuter, ou construire avec des images de confiance. Activer DCT est un peu comme appliquer un "filtre" à votre registre. Les consommateurs "voient" seulement les étiquettes d'image signées et les étiquettes d'image non signées moins désirables sont "invisibles" pour eux.

Vue de confiance

Pour le consommateur qui n'a pas activé DCT, rien sur la façon dont ils travaillent avec les images Docker ne change. Chaque image est visible qu'elle soit signée ou non.

Clés Docker Content Trust

La confiance pour une étiquette d'image est gérée grâce à l'utilisation de clés de signature. Un ensemble de clés est créé lorsqu'une opération utilisant DCT est invoquée pour la première fois. Un ensemble de clés consiste en les classes de clés suivantes :

  • Une clé hors ligne qui est la racine de DCT pour une étiquette d'image
  • Des clés de dépôt ou d'étiquetage qui signent les étiquettes
  • Des clés gérées par le serveur telles que la clé d'horodatage, qui fournit la fraîcheur des garanties de sécurité pour votre dépôt

L'image suivante décrit les diverses clés de signature et leurs relations :

Composants de confiance de contenu
Warning

La clé racine une fois perdue n'est pas récupérable. Si vous perdez toute autre clé, envoyez un email au Support Docker Hub. 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.

Vous devriez sauvegarder la clé racine quelque part en sécurité. Étant donné qu'elle n'est requise que pour créer de nouveaux dépôts, c'est une bonne idée de la stocker hors ligne dans le matériel. Pour des détails sur la sécurisation et la sauvegarde de vos clés, assurez-vous de lire comment gérer les clés pour DCT.

Signer des images avec Docker Content Trust

Dans la CLI Docker, nous pouvons signer et pousser une image conteneur avec la syntaxe de commande $ docker trust. Ceci est construit au-dessus de l'ensemble de fonctionnalités Notary. Pour plus d'informations, voir le dépôt GitHub Notary.

Un prérequis pour signer une image est un registre Docker avec un serveur Notary attaché (tel que Docker Hub). Les instructions pour mettre en place un environnement auto-hébergé peuvent être trouvées ici.

Pour signer une image Docker, vous aurez besoin d'une paire de clés de délégation. Ces clés peuvent être générées localement en utilisant $ docker trust key generate ou générées par une autorité de certification.

D'abord, nous ajouterons la clé privée de délégation au dépôt de confiance Docker local. (Par défaut, ceci est stocké dans ~/.docker/trust/). Si vous générez des clés de délégation avec $ docker trust key generate, la clé privée est automatiquement ajoutée au magasin de confiance local. Si vous importez une clé séparée, vous devrez utiliser la commande $ docker trust key load.

$ docker trust key generate jeff
Generating key for jeff...
Enter passphrase for new jeff key with ID 9deed25:
Repeat passphrase for new jeff key with ID 9deed25:
Successfully generated and loaded private key. Corresponding public key available: /home/ubuntu/Documents/mytrustdir/jeff.pub

Ou si vous avez une clé existante :

$ docker trust key load key.pem --name jeff
Loading key from "key.pem"...
Enter passphrase for new jeff key with ID 8ae710e:
Repeat passphrase for new jeff key with ID 8ae710e:
Successfully imported key from key.pem

Ensuite, nous devrons ajouter la clé publique de délégation au serveur Notary ; ceci est spécifique à un dépôt d'image particulier dans Notary connu sous le nom de Nom Globalement Unique (GUN). Si c'est la première fois que vous ajoutez une délégation à ce dépôt, cette commande initialisera également le dépôt, en utilisant une clé racine canonique Notary locale. Pour en savoir plus sur l'initialisation d'un dépôt, et le rôle des délégations, dirigez-vous vers délégations pour la confiance de contenu.

$ docker trust signer add --key cert.pem jeff registry.example.com/admin/demo
Adding signer "jeff" to registry.example.com/admin/demo...
Enter passphrase for new repository key with ID 10b5e94:

Enfin, nous utiliserons la clé privée de délégation pour signer une étiquette particulière et la pousser vers le registre.

$ docker trust sign registry.example.com/admin/demo:1
Signing and pushing trust data for local image registry.example.com/admin/demo:1, may overwrite remote trust data
The push refers to repository [registry.example.com/admin/demo]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed registry.example.com/admin/demo:1

Alternativement, une fois que les clés ont été importées, une image peut être poussée avec la commande $ docker push, en exportant la variable d'environnement DCT.

$ export DOCKER_CONTENT_TRUST=1

$ docker push registry.example.com/admin/demo:1
The push refers to repository [registry.example.com/admin/demo:1]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed registry.example.com/admin/demo:1

Les données de confiance distantes pour une étiquette ou un dépôt peuvent être visualisées par la commande $ docker trust inspect :

$ docker trust inspect --pretty registry.example.com/admin/demo:1

Signatures for registry.example.com/admin/demo:1

SIGNED TAG          DIGEST                                                             SIGNERS
1                   3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e   jeff

List of signers and their keys for registry.example.com/admin/demo:1

SIGNER              KEYS
jeff                8ae710e3ba82

Administrative keys for registry.example.com/admin/demo:1

  Repository Key:	10b5e94c916a0977471cc08fa56c1a5679819b2005ba6a257aa78ce76d3a1e27
  Root Key:	84ca6e4416416d78c4597e754f38517bea95ab427e5f95871f90d460573071fc

Les données de confiance distantes pour une étiquette peuvent être supprimées par la commande $ docker trust revoke :

$ docker trust revoke registry.example.com/admin/demo:1
Enter passphrase for signer key with ID 8ae710e:
Successfully deleted signature for registry.example.com/admin/demo:1

Application côté client avec Docker Content Trust

La confiance de contenu est désactivée par défaut dans le client Docker. Pour l'activer, définissez la variable d'environnement DOCKER_CONTENT_TRUST à 1. Cela empêche les utilisateurs de travailler avec des images étiquetées à moins qu'elles ne contiennent une signature.

Lorsque DCT est activé dans le client Docker, les commandes CLI docker qui opèrent sur des images étiquetées doivent soit avoir des signatures de contenu ou des hachages de contenu explicites. Les commandes qui opèrent avec DCT sont :

  • push
  • build
  • create
  • pull
  • run

Par exemple, avec DCT activé, un docker pull someimage:latest ne réussit que si someimage:latest est signé. Cependant, une opération avec un hachage de contenu explicite réussit toujours tant que le hachage existe :

$ docker pull registry.example.com/user/image:1
Error: remote trust data does not exist for registry.example.com/user/image: registry.example.com does not have trust data for registry.example.com/user/image

$ docker pull registry.example.com/user/image@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1: Pulling from user/image
ff3a5c916c92: Pull complete
a59a168caba3: Pull complete
Digest: sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1
Status: Downloaded newer image for registry.example.com/user/image@sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1

Informations connexes