Registres, tags, digests et provenance

Comprendre le mécanisme

Un tag est un nom de référence susceptible d’être déplacé ; un digest identifie un contenu de manifeste. Utiliser une référence par digest aide à retrouver l’artefact attendu, sans démontrer à lui seul qu’il est sans vulnérabilité. Une image multi-plateforme peut pointer vers des variantes : identifiez aussi la plateforme effectivement utilisée. La provenance et la politique de confiance font partie du choix d’image.

Raisonner et vérifier

Conservez le lien entre commit, tests, build et image poussée au registre. Un scan et une nomenclature de dépendances apportent des informations à une date donnée, pas une garantie éternelle. Une mise à jour doit être reconstruite, testée et promue de façon contrôlée. Le retour de version doit cibler un artefact connu, avec vérification de compatibilité des données.

Comprendre la mutabilité d’un nom

Un tag est une référence nommée qui peut être réaffectée selon la politique du registre. Deux lancements séparés d’un même nom ne prouvent donc pas un contenu identique. Conservez la résolution effective lors du déploiement et prévoyez la politique de mise à jour. Cette trace aide à distinguer changement de configuration et changement d’artefact lorsque le nom apparent du service reste inchangé.

Fixer un contenu ne le rend pas exempt de défauts

Un digest aide à identifier précisément le contenu choisi. Il ne corrige pas les vulnérabilités que ce contenu peut déjà posséder ou qui seront découvertes plus tard. La maintenance doit donc savoir quel artefact est exécuté puis décider de sa mise à jour. L’immuabilité d’une référence facilite cette décision ; elle ne remplace pas l’analyse des risques et la vérification du nouveau comportement.

Établir une provenance de confiance

Une empreinte correcte montre une relation avec des octets attendus, pas automatiquement la légitimité de leur producteur. Une image malveillante possède aussi une identité de contenu. Définissez les éditeurs et processus admis ainsi que les preuves pertinentes pour votre distribution. Le téléchargement depuis un emplacement connu ne doit pas devenir une confiance indéfinie dans toute future publication portant un nom ressemblant.

Limiter les credentials du registre

Lire une image, publier un nouveau contenu et supprimer des artefacts sont des capacités différentes. Distribuez aux consommateurs le périmètre nécessaire plutôt qu’un credential universel. Les outils de diagnostic et de build ne doivent pas recopier ces secrets dans leurs sorties. Une compromission doit pouvoir être reliée à ses opérations possibles et à une procédure de retrait adaptée.

Conserver ce qui permet la reprise

Une politique de rétention peut supprimer un ancien artefact nécessaire à un retour arrière. Définissez les versions qui doivent rester accessibles et leur durée utile, sans conserver aveuglément toutes les données indéfiniment. Le test de rollback doit récupérer et lancer la référence réellement conservée. L’existence d’un nom de version dans un document ne prouve pas la disponibilité de ses couches dans le registre.

Décrire l’image multi-plateforme exécutée

Une référence multi-plateforme peut conduire à des contenus adaptés à des architectures différentes. Pour une release traçable, notez la plateforme cible effectivement choisie en plus de la référence générale. Une panne spécifique à une architecture peut rester invisible sur le poste de build. Les preuves doivent donc relier la machine, le contenu résolu et le parcours exécuté.

Vérifier une signature avec une politique

La présence d’une signature ne suffit pas si le consommateur accepte n’importe quelle clé ou n’importe quel éditeur. La politique doit définir les autorités et usages admis, puis vérifier les éléments pertinents avant exécution. Le contenu signé peut encore comporter des défauts ; authenticité de distribution et sécurité de l’application restent des propriétés différentes. Documentez ce que votre contrôle de signature démontre exactement.

Un scan possède une date et un périmètre

Un scan compare un contenu à un référentiel et des règles à un moment donné. Un rapport vert ne garantit pas toute sécurité future ni l’absence de défauts inconnus. Conservez l’identité analysée, la version de l’outil et les limites du contrôle. Lorsqu’un nouveau risque apparaît, cette traçabilité permet de déterminer quelles releases sont concernées et quel contrôle complémentaire devient nécessaire.

Relier le commit à l’image déployée

Une chaîne de preuve utile relie source, tests, build et identité de l’image effectivement lancée. Un succès de test sur un commit ne couvre pas un autre contenu construit manuellement ensuite. Évitez les substitutions silencieuses entre étapes et vérifiez l’identité servie après la bascule. Le nom du projet ne suffit pas pour diagnostiquer quelle version a produit un incident.

Protéger le téléchargement et son destinataire

Le transport vers le registre doit vérifier le pair prévu selon le modèle TLS utilisé. Désactiver la vérification de certificat pour contourner une erreur retire une garantie importante. Corrigez la chaîne, le nom ou le magasin de confiance en conservant le contrôle. Cette vérification de canal complète la politique de provenance du contenu ; elle ne donne pas, seule, une assurance sur tout ce que l’image exécutera.

Atelier guidé : lire, expliquer et vérifier le code

services:
  api:
    image: example/lab-api:latest

Le fichier Compose de l’atelier utilise le tag latest. Cette référence peut rester identique dans le texte tout en visant un autre contenu au registre. Le YAML ne constitue donc pas une preuve d’immutabilité de l’artefact. Il ne dit pas non plus que le contenu est sans vulnérabilité ou que toute mise à jour est interdite.

Pour le laboratoire, relevez la référence résolue puis comparez deux publications contrôlées sous un même tag. Définissez ensuite une référence et une trace adaptées à votre processus de release. Si plusieurs plateformes sont proposées, notez celle réellement exécutée. La conclusion doit permettre de retrouver ce qui a été testé et servi, sans confondre identité des octets et légitimité ou qualité de leur producteur.