Tags versus empreintes des images de conteneur : noms mutables et adresses de contenu

Ce que c'est

Un registre OCI stocke des blobs (couches et manifestes) par adresse de contenu. La spécification de distribution (citée) définit une empreinte comme un identifiant unique créé à partir d'un hash cryptographique du contenu d'un blob, et un tag comme un pointeur personnalisé et lisible par les humains vers un manifeste ; l'empreinte d'un manifeste peut avoir zéro, un ou plusieurs tags qui y renvoient. La section descripteur de la spécification d'image (citée) explique que l'empreinte joue le rôle d'identifiant de contenu et que du contenu récupéré depuis une source non fiable peut être vérifié en recalculant cette empreinte. Une référence a donc deux formes : registry/repo:tag se résout via un pointeur mutable, tandis que registry/repo@sha256:<hex> désigne des octets. La référence de la CLI Docker (citée) appelle cette seconde forme un pull par identifiant immuable.

Pourquoi c'est important

python:3.12-slim aujourd'hui et le mois prochain sont des images différentes portant le même nom ; myapp:latest sur deux nœuds peut correspondre à deux builds différents. Un retour en arrière « vers le tag précédent » peut récupérer quelque chose de plus récent que ce qui tournait avant, si le tag a été repoussé entre-temps. Les analyses de vulnérabilités, les attestations de provenance et les signatures s'attachent toutes à des empreintes, donc un déploiement décrit seulement par tag ne peut pas être rattaché à son résultat d'analyse. Inversement, une empreinte n'a aucun sens pour un être humain sans une trace de ce à partir de quoi elle a été construite.

Comment l'appliquer

• Pousser un build une seule fois sous une identité immuable (sha-<commit> ou un tag de version) et laisser l'intégration continue afficher l'empreinte résultante ; la stocker avec la version.
• Déployer par empreinte : image: registry/app@sha256:… dans les manifestes, ou résoudre le tag en empreinte au moment du déploiement et la consigner dans le manifeste rendu.
• Épingler les images de base dans les Dockerfiles sous la forme FROM image:tag@sha256:…, afin que le tag documente l'intention et que l'empreinte fixe le contenu ; rafraîchir les deux via des pull requests de mise à jour relues.
• N'utiliser les tags flottants (latest, 3.12) que pour un usage interactif et pour découvrir ce qu'il faut épingler ensuite.
• Traiter un tag multi-plateforme avec prudence : il pointe vers un index d'images dont l'empreinte diffère des empreintes des manifestes par plateforme qu'il contient.

Pièges

Les listings de registre sont généralement organisés par tag, donc un manifeste sans tag est facile à négliger bien qu'il reste récupérable par empreinte et occupe toujours de l'espace de stockage. La spécification de distribution permet à un registre d'implémenter la suppression de tag indépendamment de la suppression de manifeste, donc retirer un tag ne libère pas en soi le manifeste ni ses couches. Reconditionner une image (par exemple recompresser des couches ou reconstruire avec des métadonnées différentes) change l'empreinte même si les fichiers à l'intérieur sont identiques ; les signatures et les attestations, en revanche, sont stockées à côté de l'image et ne la modifient pas.