Un registre conserve les images utilisées pour déployer une application. Sans règles de nommage, de scan et de rétention, une équipe peut perdre la trace d’une version ou conserver des images vulnérables. Voici une organisation simple pour une PME.
Identifier chaque image précisément
Un tag comme latest ne suffit pas pour reproduire un déploiement. Utilisez un tag lié à une version de code et conservez le digest immuable de l’image publiée. Le pipeline doit enregistrer le commit, l’image de base et les outils de construction utilisés.
Séparez les images de test, de préproduction et de production selon les besoins d’accès. Une image validée peut être promue vers un autre environnement sans être reconstruite, afin d’éviter qu’un changement invisible apparaisse entre les deux étapes.
Réduire le contenu de l’image
Choisissez une image de base adaptée au runtime et supprimez les outils qui ne servent pas à exécuter l’application. Un conteneur final n’a généralement pas besoin du compilateur, du gestionnaire de paquets ou des fichiers temporaires de construction. Une construction en plusieurs étapes aide à garder ces éléments hors de l’image livrée.
Vérifiez les dépendances incluses. Une bibliothèque présente indirectement peut recevoir une alerte même si elle n’apparaît pas dans le fichier principal du projet. Conservez le fichier de verrouillage et reconstruisez régulièrement avec des versions compatibles, après avoir exécuté les tests appropriés.
Scanner avant publication
Ajoutez un scan de vulnérabilités avant la publication et un contrôle périodique des images déjà stockées. Définissez les seuils qui bloquent une livraison et ceux qui créent une tâche de suivi. Une alerte doit citer le paquet, la version, le composant concerné et la correction disponible lorsque le scanner fournit cette information.
Le scan ne prouve pas que l’application est sûre. Il ne détecte pas toutes les erreurs de configuration, les secrets dans les variables ou les permissions trop larges. Vérifiez séparément les paramètres d’exécution, l’utilisateur du conteneur et les accès réseau.
Gérer les signatures et les accès
Limitez les personnes et les pipelines qui peuvent publier une image. Les déploiements doivent tirer depuis un registre approuvé et refuser les images dont la provenance n’est pas connue. La signature ou l’attestation peut aider à relier une image à son processus de construction, si votre plateforme les supporte.
Les identifiants du registre appartiennent au pipeline ou à l’orchestrateur, avec les droits nécessaires. Ils ne doivent pas être copiés dans le Dockerfile ni dans le dépôt. Pour plus de détails, consultez l’article sur les secrets dans les pipelines CI/CD.
Définir une rétention
Conservez les images nécessaires aux retours arrière et aux audits, puis supprimez les versions inutiles selon une règle connue. Une rétention trop courte empêche un retour après plusieurs semaines. Une rétention infinie augmente les coûts et rend la recherche plus difficile.
Avant de supprimer une image, vérifiez les manifestes déployés, les environnements de test et les branches encore actives. Excluez les versions liées à une restauration en cours. Le nettoyage doit produire un journal indiquant les images supprimées et la règle utilisée.
Relier le registre au déploiement
Ajoutez à chaque déploiement le tag, le digest et le commit. Les journaux doivent permettre de répondre à deux questions : quelle image tourne maintenant et qui l’a publiée ? Ces informations accélèrent le diagnostic et évitent de reconstruire une version à partir d’une mémoire approximative.
Testez la récupération d’une image depuis un environnement isolé. Vérifiez le certificat, l’authentification, les quotas et le comportement si le registre est temporairement indisponible. Notre guide sur le retour arrière complète les contrôles liés aux versions.
Sources : Docker, image tags, CNCF, Cloud Native Security.