Conteneurs : corriger l’image, pas l’instance
En production, modifier un conteneur en cours d’exécution crée une configuration impossible à reproduire. Le modèle utile consiste à reconstruire, valider et redéployer un artefact traçable.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
La conteneurisation ne règle pas, à elle seule, la gestion des correctifs. Elle déplace le point de contrôle. Sur un serveur administré de manière classique, une équipe peut installer un paquet ou modifier un fichier directement. Dans un environnement conteneurisé, cette intervention est techniquement possible, mais elle constitue généralement une mauvaise pratique : la modification disparaît au prochain redémarrage et n’existe ni dans l’image d’origine ni dans le système de construction. Deux instances supposées identiques ne le sont alors plus. Pour une organisation régulée, le problème dépasse la cohérence technique. Il devient difficile d’établir quelle version était réellement exécutée, qui a autorisé le changement et comment la reproduire.
Déplacer la preuve vers l’image
Le modèle cible consiste à traiter l’image comme l’unité de changement. Une vulnérabilité dans un composant de base ne doit pas conduire à réparer chaque instance. Il faut mettre à jour l’entrée concernée, reconstruire l’image, exécuter les contrôles prévus, puis promouvoir le même artefact jusqu’à la production. L’image déployée doit être identifiée par son condensat cryptographique, et non uniquement par une étiquette modifiable. Les sources, paramètres de construction, dépendances, résultats de tests, nomenclatures de composants logiciels et décisions d’approbation forment alors une chaîne de preuves. Cette chaîne n’atteste pas que le logiciel est exempt de défauts. Elle permet de démontrer ce qui a été construit et déployé.
Les contrôles qui rendent le modèle exploitable
- Versionner les fichiers de construction et maîtriser les images de base. Une référence flottante peut introduire un contenu différent sans modification visible du code. Le condensat permet de fixer l’entrée réellement utilisée et de relier une reconstruction à ses composants.
- Construire dans un environnement isolé et journalisé. Les droits de publication vers le registre d’images doivent être distincts des droits de développement. Une compilation réussie n’est pas une autorisation de mise en production.
- Analyser les dépendances et produire une nomenclature des composants logiciels. Un scanner signale des éléments connus ; il ne prouve pas l’absence de vulnérabilité. Les exceptions doivent être limitées dans le temps, motivées et rattachées à un responsable.
- Promouvoir le même artefact entre les environnements. Reconstruire séparément pour la recette et la production revient à valider un objet puis à en déployer un autre. Les paramètres propres à l’environnement doivent rester extérieurs à l’image.
- Bloquer les déploiements qui ne respectent pas la politique : provenance absente, signature non reconnue, composant interdit ou exécution avec des privilèges excessifs. Un contrôle seulement documenté, mais contournable sans trace, reste fragile.
Adopter sans ajouter une plateforme inutile
Ce modèle devient pertinent lorsque plusieurs instances doivent rester cohérentes, que les mises en production sont fréquentes ou que la preuve de version repose encore sur des inventaires manuels. Il est également utile quand le délai de correction dépend davantage de la reconstruction et de la qualification que de l’installation elle-même. En revanche, conteneuriser ne rend pas obligatoire une plateforme d’orchestration complète. Pour quelques services stables, son coût d’exploitation, ses mécanismes de sécurité et son propre cycle de mise à jour peuvent dépasser le bénéfice attendu. La conteneurisation et l’orchestration sont deux décisions distinctes. Les charges avec état exigent aussi un traitement spécifique : stockage persistant, sauvegarde, cohérence applicative et compatibilité des données lors d’un retour arrière. Enfin, l’interdiction de toute intervention directe doit être accompagnée d’outils de diagnostic. Sans journaux, métriques, traces et procédure d’accès d’urgence, l’équipe remplacera une dérive de configuration par une perte de capacité d’enquête.
Une image dite immuable n’est pas une garantie absolue. Le registre peut être compromis, les secrets peuvent être injectés au démarrage et la configuration d’exécution peut modifier fortement le comportement du conteneur. Le contrôle doit donc couvrir toute la chaîne : construction, stockage, admission, déploiement et exécution. Le retour arrière doit également être testé ; restaurer une ancienne image ne suffit pas si les données ou les interfaces ont évolué de manière incompatible.
Containerisation does not, by itself, solve patch management. It moves the control point. On a conventionally managed server, a team can install a package or edit a file directly. In a containerised environment, this remains technically possible, but it is usually poor practice: the change disappears at the next restart and exists neither in the original image nor in the build system. Two instances that are meant to be identical are no longer the same. For a regulated organisation, the issue extends beyond technical consistency. It becomes difficult to establish which version was actually running, who authorised the change and how it can be reproduced.
Move the Evidence to the Image
The target operating model treats the image as the unit of change. A vulnerability in a base component should not lead to each instance being repaired individually. The relevant input must be updated, the image rebuilt, the required checks performed, and the same artefact promoted through to production. The deployed image should be identified by its cryptographic digest, not only by a mutable tag. Sources, build parameters, dependencies, test results, software bills of materials and approval decisions then form an evidence chain. This chain does not establish that the software is free from defects. It demonstrates what was built and deployed.
Controls That Make the Model Operable
- Version build files and control base images. A floating reference can introduce different content without any visible code change. A digest fixes the actual input and links a rebuild to its components.
- Build in an isolated, logged environment. Permissions to publish to the image registry should be separate from development permissions. A successful build is not an authorisation to deploy to production.
- Scan dependencies and produce a software bill of materials. A scanner reports known findings; it does not prove the absence of vulnerabilities. Exceptions should be time-limited, justified and assigned to an accountable owner.
- Promote the same artefact between environments. Building separately for testing and production means validating one object and deploying another. Environment-specific parameters should remain outside the image.
- Block deployments that do not meet policy: missing provenance, an unrecognised signature, a prohibited component or excessive privileges. A control that exists only in documentation and can be bypassed without a trace remains weak.
Adopt Without Adding an Unnecessary Platform
This model becomes relevant when several instances must remain consistent, releases are frequent, or version evidence still relies on manual inventories. It is also useful when remediation time depends more on rebuilding and qualification than on installation itself. Containerisation does not, however, make a full orchestration platform mandatory. For a small number of stable services, its operating cost, security mechanisms and own update cycle may outweigh the expected benefit. Containerisation and orchestration are separate decisions. Stateful workloads also require specific treatment: persistent storage, backups, application consistency and data compatibility during rollback. Finally, a ban on direct intervention must be supported by diagnostic tools. Without logs, metrics, traces and an emergency access procedure, the team will replace configuration drift with a reduced ability to investigate incidents.
An image described as immutable is not an absolute guarantee. The registry can be compromised, secrets can be injected at startup, and runtime configuration can materially alter container behaviour. Controls must therefore cover the entire chain: build, storage, admission, deployment and execution. Rollback must also be tested; restoring an older image is not enough if data or interfaces have changed incompatibly.