Promouvoir un artefact entre environnements

La promotion est le déplacement contrôlé d’un artefact déjà construit vers un niveau d’exposition supérieur, par exemple du test vers la préproduction puis la production. Le principe paraît banal, jusqu’au moment où une reconstruction, un secret différent ou une approbation sans preuve transforme la chaîne de livraison en machine à produire des écarts.

→ Lire l’explication complète de la marmotte

Promotion d’artefact et immutabilité

Une promotion ne consiste pas à refaire un déploiement avec la branche main, un tag Git ou une image portant latest. Elle consiste à promouvoir le même artefact immuable, identifié par son contenu. Pour une image de conteneur, cet identifiant est un digest, par exemple sha256:.... Pour un paquet, c’est une version accompagnée d’une somme cryptographique. Pour un binaire, c’est son empreinte et sa signature.

Le compromis central est net : l’immutabilité réduit les écarts entre environnements, mais impose une discipline de configuration et de stockage plus coûteuse. On gagne la capacité de démontrer quel code a été livré. On paie avec des registres d’artefacts, des métadonnées de provenance, des politiques de rétention et l’interdiction de corriger discrètement un paquet après coup. Il faut accepter ce prix. Recompiler pour chaque environnement annule le bénéfice principal de la promotion : il devient impossible d’affirmer que le binaire testé est celui exécuté en production.

Une chaîne CI/CD (Continuous Integration / Continuous Delivery) doit donc séparer trois objets :

l’artefact exécutable, construit une fois ;
la configuration propre à l’environnement ;
les secrets injectés au plus tard, depuis un système de gestion de secrets.

Un fichier de configuration intégré dans l’image peut être promu. Un mot de passe, une clé privée ou un jeton d’accès ne le peut pas. Les secrets doivent rester hors de l’artefact et être résolus à l’exécution avec une identité de charge de travail. Mettre un fichier .env dans une image parce que « le registre est privé » reste une fuite de secret avec contrôle d’accès décoratif.

La promotion doit transporter des preuves avec l’artefact : résultat des tests, rapport de vulnérabilités, nomenclature logicielle, signature, référence de source et identité du constructeur. Une nomenclature logicielle décrit les composants inclus dans un livrable. Sans cette trace, une alerte sur une bibliothèque vulnérable déclenche une chasse archéologique, activité qui ne figure curieusement dans aucun diagramme de livraison continue.

La promotion d’un digest n’empêche pas l’exécution d’un artefact malveillant signé par une identité compromise. Elle garantit l’identité du contenu, pas sa qualité, ni l’honnêteté de son constructeur. La sécurité du code relève aussi de la gouvernance, du contrôle des dépendances et de la protection des identités de pipeline.

Environnements de promotion et dérive de configuration

Un environnement n’est pas une couleur sur un pipeline. C’est un ensemble cohérent de contrôles : identité, réseau, données, secrets, règles d’admission, supervision et capacité de retour arrière. La production ne doit pas seulement avoir davantage de réplicas. Elle doit réduire les privilèges, filtrer les sorties réseau, interdire les images non signées et journaliser les actions de déploiement.

La dérive de configuration est le défaut le plus courant. Elle apparaît quand les manifestes, paramètres de compilation, versions de moteur d’exécution ou règles réseau divergent sans contrôle explicite. Une image testée avec une bibliothèque système en version A, puis reconstruite avec une version B pour la production, n’a pas été promue. Elle a été remplacée.

Le bon découpage consiste à figer le socle d’exécution et à externaliser les paramètres attendus : URL de service, identifiants de ressources, limites de capacité et options fonctionnelles. Ces paramètres doivent être validés par schéma et versionnés. Une variable d’environnement librement nommée permet autant de souplesse qu’un tournevis dans un panneau électrique : c’est vrai, mais ce n’est pas une stratégie d’exploitation.

Les données exigent un traitement particulier. Promouvoir un code qui attend un schéma de base de données inexistant échoue immédiatement. Promouvoir une migration destructive peut réussir techniquement et rendre le retour arrière impossible. Toute migration doit donc être classée :

extensive : ajout compatible, comme une colonne nullable ou une table nouvelle ;
contractive : suppression ou changement incompatible ;
transitoire : coexistence temporaire de deux formats.

La séquence sûre suit le modèle expansion puis contraction : déployer le code compatible avec les deux états, migrer les données, basculer les lectures, puis retirer l’ancien format après observation. Le rollback applicatif ne restaure pas les données supprimées. Cette limite doit être documentée avant la promotion, pas découverte avec une sauvegarde qui contient exactement le même état déjà corrompu.

Les contrôles réseau et identitaires doivent aussi être promus comme du code. Les notions abordées dans l’architecture cyber s’appliquent ici sans poésie particulière : une charge de travail de test ne doit pas obtenir par héritage un accès à une base de production, même si le nom du compte contient le mot readonly.

Politique de promotion, approbation et séparation des rôles

Une politique de promotion décide quelles preuves autorisent le passage d’un environnement à l’autre. Elle ne doit pas reposer sur un bouton « approve » isolé. Une approbation humaine sans contexte est une signature au bas d’un formulaire dont le contenu change pendant la lecture.

La règle recommandée est la suivante : automatiser les décisions vérifiables, réserver l’approbation humaine aux exceptions et aux changements dont le risque ne se déduit pas des tests. Les contrôles automatiques doivent au minimum vérifier :

l’existence d’un digest immuable ;
une signature associée à une identité de build autorisée ;
la provenance reliant l’artefact à une révision de source ;
les résultats de tests attendus ;
l’absence de vulnérabilité bloquante selon une politique explicite ;
la conformité des manifestes d’infrastructure ;
l’autorisation du dépôt, du projet et de la cible.

Le RBAC (Role-Based Access Control), contrôle d’accès fondé sur les rôles, doit séparer la capacité de construire, de modifier une politique et de promouvoir en production. Une même identité ne doit pas pouvoir modifier le pipeline, affaiblir le contrôle de signature et déclencher le déploiement. Cette séparation limite l’impact d’un jeton compromis et évite qu’une exception urgente devienne une porte permanente.

Les approbations doivent être liées au digest et expirer. Approuver un nom d’image mutable revient à approuver une boîte étiquetée sans regarder son contenu. Toute approbation doit inclure l’artefact précis, la cible, la politique évaluée et les preuves consultées. Le journal d’audit doit être append-only ou exporté vers un système distinct, sinon l’attaquant qui compromet le pipeline peut aussi réécrire l’histoire. C’est pratique pour les romans, moins pour une investigation.

La promotion ne remplace pas une revue de code, un test d’intrusion ni une analyse de menace. Elle orchestre des décisions sur des preuves disponibles. Si la règle de détection est insuffisante, le pipeline appliquera très vite une mauvaise décision. L’automatisation accélère aussi les erreurs, avec une ponctualité presque émouvante.

Exemple de promotion d’une image par digest

L’exemple suivant utilise skopeo, un outil de copie d’images de conteneur, pour copier une image immuable entre deux référentiels. La commande ne reconstruit rien : elle copie le manifeste et les couches référencées par le digest.

# Prérequis : skopeo authentifié sur les deux registres.
# Le digest provient du résultat de build et non d'un tag mutable.
DIGEST="sha256:8f7d9b6a0e2c4f3a1b5d7e9c0a2b4d6e8f1a3c5e7b9d0f2a4c6e8b0d2f4a6c8"

# Vérifier que l'artefact source existe et récupérer son manifeste.
skopeo inspect \
  "docker://registry-build.example/app@${DIGEST}"

# Promouvoir exactement cet artefact vers le registre de production.
# Le tag de lisibilité est secondaire : le digest reste la référence d'autorité.
skopeo copy \
  "docker://registry-build.example/app@${DIGEST}" \
  "docker://registry-prod.example/app:2026.09.25"

# Vérifier que le tag cible résout vers le digest attendu.
skopeo inspect \
  --format '{{.Digest}}' \
  "docker://registry-prod.example/app:2026.09.25"

La dernière valeur doit être strictement égale à DIGEST. Une différence indique une substitution, une transformation de registre ou une erreur de référence. Le pipeline doit échouer dans ce cas. Un tag est un pointeur mutable, pas une preuve d’intégrité.

Dans une plateforme d’orchestration, l’admission doit ensuite exiger le digest dans le manifeste exécuté. Déployer registry-prod.example/app:2026.09.25 sans verrouillage de digest réintroduit une ambiguïté : un acteur autorisé à déplacer le tag peut modifier le contenu exécuté sans modifier le manifeste. Le digest dans le manifeste est plus verbeux. La sécurité a parfois l’élégance d’un formulaire fiscal, mais le formulaire fiscal ne change pas de binaire entre deux lectures.

Surface d’attaque de la promotion

Le pipeline de promotion est une cible à privilège élevé. Il possède souvent le droit de lire les artefacts, de récupérer des secrets d’environnement et de modifier un état de production. Le traiter comme un simple robot de build est une erreur d’architecture.

Les attaques fréquentes suivent quelques chemins prévisibles :

compromission d’identité de pipeline : un jeton volé promeut ou remplace un artefact ;
substitution d’artefact : un tag mutable pointe vers une image différente après validation ;
empoisonnement de dépendance : une dépendance compromise entre dans le build légitime ;
contournement de politique : une exception permanente ou une règle d’admission désactivée ouvre la cible ;
exfiltration de secrets : les journaux de build, caches ou variables d’environnement révèlent des secrets ;
attaque sur le registre : une suppression, rétention trop courte ou altération rend le rollback impossible.

La réponse commence par des identités courtes et fédérées pour les jobs, plutôt que des clés statiques stockées dans le système CI/CD. Les clés de signature doivent être isolées dans un HSM (Hardware Security Module), module matériel qui protège les opérations cryptographiques et empêche l’export normal de la clé privée. Les principes de cryptographie appliquée restent valables : une signature n’a de valeur que si la clé, la politique de vérification et la révocation sont correctement exploitées.

La rotation d’une clé de signature doit prévoir une période de double confiance. Signer immédiatement avec une nouvelle clé sans distribuer sa clé publique aux validateurs bloque les promotions. Révoquer une ancienne clé sans conserver la capacité de vérifier les artefacts historiques détruit l’audit. La politique doit distinguer « autorisée pour de nouvelles signatures » et « reconnue pour vérifier l’historique ».

Les sauvegardes doivent couvrir le registre, les métadonnées de provenance, les politiques, les journaux d’audit et les configurations de déploiement. Sauvegarder uniquement les images ne suffit pas : sans manifeste, sans digest de référence et sans configuration compatible, le retour arrière devient une restauration de musée. La supervision doit alerter sur les échecs de signature, les promotions hors fenêtre prévue, les modifications de politique, les suppressions d’artefacts et l’approche des seuils de rétention.

🐝 Ce qui arrive si on s’en passe

Sans promotion d’un artefact unique, chaque environnement reçoit sa propre construction, et les tests réussis en préproduction certifient un objet qui ne sera jamais exécuté en production. Un serveur de construction compromis pendant la seule construction de production n’affecte que la version réellement exposée, pendant que tous les voyants de validation restent au vert sur une copie saine. Un défaut observé en production ne se reproduit pas en préproduction, puisque les binaires diffèrent, et l’équipe passe des heures à chercher une anomalie dans le mauvais environnement. La chaîne de livraison produit alors des écarts avec une régularité industrielle, ce qui est au moins une forme de fiabilité.

🦫 Explication de la marmotte 🍫

Promouvoir signifie faire avancer un même logiciel déjà fabriqué vers des systèmes de plus en plus sensibles. Le logiciel reçoit d’abord une identité liée à son contenu exact. Cette identité permet de vérifier que le programme testé est bien celui qui sera exécuté plus tard, sans le fabriquer une seconde fois.

Avant chaque passage, une règle vérifie des éléments précis : tests terminés, origine du code connue, composants recensés, absence de défaut bloquant selon la règle choisie et autorisation de la cible. Certaines décisions peuvent être automatiques. Une validation humaine reste nécessaire lorsqu’un changement risque de modifier les données, les accès ou le fonctionnement d’un service.

Les réglages propres à chaque environnement sont séparés du programme. Les mots de passe et les clés secrètes ne sont pas inclus dans le logiciel : ils sont fournis seulement au moment où il démarre. Cela évite qu’un secret se retrouve copié dans un dépôt, un registre ou un journal.

Le processus peut échouer si l’identité du logiciel ne correspond plus, si une vérification manque, si une règle a été modifiée ou si les données attendues ne sont pas prêtes. Revenir en arrière est possible pour le programme, mais pas toujours pour les données déjà transformées ou supprimées. Il faut donc conserver les anciennes versions, les preuves de vérification, les réglages et les journaux, puis surveiller les actions de promotion.