Ce que vous voyez
Une image absente, corrompue ou non approuvée bloque la reprise; aucun remplacement silencieux n’est permis.
État d’avancement:Kit de reprise local contrôléfiche de référencemise en service interdite pour l’instantÉtat réel:Bundle local partiellement prouvépage d’autorité composantpromotion NO-GO
Choisissez votre lectureCommencez par la vue sans jargon si vous découvrez le sujet.
À qui s’adresse chaque lecture?
Je veux comprendre: direction, équipes métier, communication, achats et première visite. Exploitation: opérateur, support et astreinte. Vue architecte: architecte, ingénieur et sécurité. Tout afficher: revue complète de la fiche.
« Je veux comprendre » affiché. Ce choix sera repris sur les autres fiches. La décision de mise en service et les risques restent toujours visibles.
Comprendre cette fonction en 60 secondes
Le résumé donne le rôle, le trajet, le risque, le responsable et la limite de preuve en moins d’une minute. Les dépendances et exemples restent disponibles juste après, sans jargon imposé.
Résumé essentiel
Ce que c’est et à quoi cela sert
Garder un kit de reprise vérifiable sur la machine.
Conserver localement la bonne image de reprise sans téléchargement improvisé pendant l’incident.
Une comparaison utile
Comme une trousse de secours scellée: présente, identifiable et inutilisable si le sceau ne correspond pas.
Ce qui entre
Une restauration doit pouvoir démarrer alors que le réseau ou le registre est indisponible.
Qui en bénéficie et quel résultat attendre
L’opérateur retrouve une image liée aux sources attendues et contrôlée avant usage.
L’équipe qui décide si une version peut avancer.
État actuel
Kit de reprise local contrôlé. PROUVÉ: image contrôlée. PARTIEL: réparation. NON PROUVÉ: signature. Mise en service interdite pour l’instant.
Risque principal
Une image absente, corrompue ou non approuvée bloque la reprise; aucun remplacement silencieux n’est permis.
Responsable
Responsable de l’assurance du kit de reprise. Autorité de décision: Approbateur indépendant de la chaîne de fabrication.
Décision suivante
Autoriser le kit uniquement après une signature vérifiable, un inventaire logiciel, une règle de vulnérabilité, un test sans réseau, une réparation exercée et un nettoyage borné.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Une restauration doit pouvoir démarrer alors que le réseau ou le registre est indisponible.
Ce dont il dépend
Des versions approuvées, de preuves de construction et d’une autorisation avant tout déploiement.
Comment le service continue
La promotion reste bloquée et la dernière version approuvée est conservée.
En cas de panne et pour vos données
Si la trousse de secours est absente ou abîmée, la réparation est refusée plutôt que de risquer un mauvais contenu. Tout reste rangé sur la machine; remettre d’aplomb une trousse durablement abîmée n’est pas encore démontré.
Preuve attendue avant la prochaine étape
Archive OCI et keeper durci observés localement; résidus temporaires nettoyés, mais release signée, repair durable, collecte des images orphelines et runner CI non prouvés.
Statut expliqué
Le kit local sait vérifier qu’il utilise la bonne image et conserve cette image sans la faire tourner ni lui donner le réseau. Il refuse les archives inattendues et nettoie ses restes temporaires. Il ne démontre pas encore comment remplacer en sécurité un bundle durable abîmé, ni comment garantir qu’aucune ancienne image inutile ne reste sur l’hôte. Publier une release signée avec inventaire logiciel et seuil de vulnérabilité, construire sans réseau depuis des paquets approuvés, tester la réparation d’un bundle durable corrompu et attester la collecte des images orphelines.
Exemple concret
Une restauration doit pouvoir démarrer alors que le réseau ou le registre est indisponible. L’opérateur retrouve une image liée aux sources attendues et contrôlée avant usage.
Voir l’exemple technique précis
L’installateur vérifie la structure OCI, les digests, les labels et le source digest, retire le tag temporaire puis conserve l’image par un conteneur arrêté sans réseau.
Voir les questions et réponses selon votre rôle
Les six lectures ci-dessous reprennent les mêmes faits. Elles ne créent pas une seconde source de vérité.
- Direction
- Question: Peut-on compter sur cette fonction aujourd’hui?
Réponse: Le kit local sait vérifier qu’il utilise la bonne image et conserve cette image sans la faire tourner ni lui donner le réseau. Il refuse les archives inattendues et nettoie ses restes temporaires. Il ne démontre pas encore comment remplacer en sécurité un bundle durable abîmé, ni comment garantir qu’aucune ancienne image inutile ne reste sur l’hôte. Autoriser le kit uniquement après une signature vérifiable, un inventaire logiciel, une règle de vulnérabilité, un test sans réseau, une réparation exercée et un nettoyage borné. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Conserver localement la bonne image de reprise sans téléchargement improvisé pendant l’incident. L’opérateur retrouve une image liée aux sources attendues et contrôlée avant usage. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Des versions approuvées, de preuves de construction et d’une autorisation avant tout déploiement. Publier une release signée avec inventaire logiciel et seuil de vulnérabilité, construire sans réseau depuis des paquets approuvés, tester la réparation d’un bundle durable corrompu et attester la collecte des images orphelines. Preuve attendue: Archive OCI et keeper durci observés localement; résidus temporaires nettoyés, mais release signée, repair durable, collecte des images orphelines et runner CI non prouvés. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Conserver localement la bonne image de reprise sans téléchargement improvisé pendant l’incident. Ne présentez pas cette fonction comme disponible en production: Le kit local sait vérifier qu’il utilise la bonne image et conserve cette image sans la faire tourner ni lui donner le réseau. Il refuse les archives inattendues et nettoie ses restes temporaires. Il ne démontre pas encore comment remplacer en sécurité un bundle durable abîmé, ni comment garantir qu’aucune ancienne image inutile ne reste sur l’hôte. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable de l’assurance du kit de reprise. Autorité de décision: Approbateur indépendant de la chaîne de fabrication. Bloquer la promotion, conserver la dernière version approuvée et prévenir l’équipe plateforme. - Technique
- Question: Où sont les contrats exacts?
Réponse: Utilisez la « Vue architecte ». Elle montre les entrées, les sorties, les interfaces, les données, la sécurité et les preuves provenant de la fiche d’autorité.
Trajet simple, de la situation au résultat
Le trajet montre ce qui déclenche cette fonction, le service qu’elle rend et le résultat obtenu. Il reste lisible sans fonction interactive.
Suivre le flux
Partie documentée: Garder un kit de reprise vérifiable sur la machine.
La fabrication prend seulement les outils de reprise attendus et calcule leur empreinte.
L’image et son archive sont contrôlées avant publication, sans accepter de contenu inattendu.
Le kit est publié d’un seul bloc, son nom temporaire est retiré et un garde inerte protège l’image locale.
Les restes temporaires sont réparés; le remplacement d’un kit durable corrompu et la collecte des anciennes images restent à prouver.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre. Les contrats exacts restent dans la « Vue architecte ».
Étape 1 sur 4: La fabrication prend seulement les outils de reprise attendus et calcule leur empreinte.
Impact utile: L’opérateur retrouve une image liée aux sources attendues et contrôlée avant usage.
En cas de panne: Une image absente, corrompue ou non approuvée bloque la reprise; aucun remplacement silencieux n’est permis.
Responsable: Responsable de l’assurance du kit de reprise. Autorité de décision: Approbateur indépendant de la chaîne de fabrication.
Premiers gestes en cas de problème
Reconnaître ce qui se passe, protéger le service et prévenir le bon responsable sans improviser.
Première action sans risque
Bloquer la promotion, conserver la dernière version approuvée et prévenir l’équipe plateforme.
Solution de secours
La promotion reste bloquée et la dernière version approuvée est conservée.
Qui prévenir et où lire les preuves
Responsable de l’assurance du kit de reprise. Autorité de décision: Approbateur indépendant de la chaîne de fabrication. La procédure de production reste à créer et valider avant la mise en service. Ouvrir la fiche d’architecture et de preuve du domaine.
Besoin d’un terme technique? Ouvrir les définitions
- OCI
- format standard d’image de conteneur
- SBOM
- inventaire des composants logiciels
- Keeper
- conteneur arrêté qui protège une image locale contre une suppression ordinaire
Décision actuelle: mise en service interdite pour l’instant. Le kit local sait vérifier qu’il utilise la bonne image et conserve cette image sans la faire tourner ni lui donner le réseau. Il refuse les archives inattendues et nettoie ses restes temporaires. Il ne démontre pas encore comment remplacer en sécurité un bundle durable abîmé, ni comment garantir qu’aucune ancienne image inutile ne reste sur l’hôte. Ce qui reste à faire: Publier une release signée avec inventaire logiciel et seuil de vulnérabilité, construire sans réseau depuis des paquets approuvés, tester la réparation d’un bundle durable corrompu et attester la collecte des images orphelines.Décision actuelle: promotion NO-GO, pas de mise en production. PROUVÉ localement: validation d’une archive OCI à membres fermés, digests de blobs et identité d’image, liaison au digest des sources de reprise, publication atomique, nettoyage des résidus de staging, retrait du tag de build et keeper arrêté avec network=none, entrypoint /bin/false, utilisateur non-root, rootfs read-only, capacités supprimées et no-new-privileges. Le lab systemd observe zéro tag temporaire après réparation de résidus et la persistance du bundle et du keeper après reboot. PARTIEL: une archive corrompue est rejetée fail-closed et les résidus temporaires sont réparés, mais aucun exercice accepté ne remplace un bundle durable corrompu ni n’atteste une collecte bornée de toutes les images orphelines. NON PROUVÉ: signature externe, SBOM, politique CVE, build hors ligne et runner CI autorisé. L’image du lab a encore utilisé le réseau vers les dépôts Alpine. Verdict NO-GO. Blockers: Release signée, SBOM, décision CVE, provenance des paquets, build offline, repair drill du bundle durable, inventaire avant/après des images et attestation CI indépendante.
Opérer le composant
Responsabilité, séquence nominale, panne et niveau de service attendu.
| Owner et rôle | Séquence nominale | Mode dégradé | Observabilité et SLO |
|---|---|---|---|
| Conserve une image de reprise liée aux sources, utilisable sans téléchargement improvisé. Owner assurance release de reprise. Non-rôle: Ne signe pas la release, ne produit pas de SBOM, ne garantit pas la politique CVE et ne répare pas encore de façon prouvée un bundle durable corrompu. | L’installateur vérifie la structure OCI, les digests, les labels et le source digest, retire le tag temporaire puis conserve l’image par un conteneur arrêté sans réseau. | PARTIEL: les archives corrompues sont refusées et le staging stale est nettoyé; la réparation d’un bundle durable corrompu et la collecte générale des images orphelines ne sont pas exercées. | Le niveau de preuve est Bundle local partiellement prouvé. Aucun SLO de production n’est acquis; l’owner doit mesurer disponibilité, erreurs, saturation et reprise avant promotion. |
Panne, reprise et surveillance
Modes de panne connus, comportement de reprise et signaux à mesurer avant toute mise en service.
| Modes de panne | Reprise après incident | Signaux à mesurer |
|---|---|---|
| Le bundle et le keeper persistent après reboot selon le lab systemd, qui observe aussi zéro tag temporaire après réparation des résidus. Aucun exercice accepté ne remplace un bundle durable corrompu. Action humaine requise: bloquer la promotion, conserver la dernière version approuvée et prévenir l’équipe plateforme. | Signaux existants: validation OCI observée localement, nettoyage du staging, lab systemd (persistance après reboot, zéro tag temporaire). Aucun signal de production. Avant promotion: mesurer disponibilité, erreurs, saturation et reprise; signature externe, SBOM, politique CVE, build hors ligne et runner CI autorisé restent non prouvés. |
Déplier ou replier les détails d’architecture
Contrat d’architecture
Entrées, sorties, protocoles, données, dépendances et configuration.
| Amont et entrées | Aval et sorties | Interfaces et trust boundary | État, données et déploiement |
|---|---|---|---|
| Sources de backup et restore, Dockerfile, release root-owned et daemon Docker local attesté. | Image de reprise locale, archive OCI, pin d’identité, keeper durci et opérations restore/recovery. | Archive OCI fermée, digests, pin d’image, Docker Unix local attesté et keeper inerte sans réseau. | PROUVÉ localement: validation OCI, source liée, publication atomique, persistance après reboot et zéro tag temporaire après réparation de résidus. Déploiement: Bundle et image exercés uniquement dans une VM locale jetable; aucune distribution ou installation production. |
Frontière de confiance: Zone privée, exercée uniquement dans une VM locale jetable, sans exposition publique. Une archive OCI à membres fermés entre et est contrôlée (digests, labels, source digest); l’image retenue est conservée par un keeper arrêté avec network=none. Le daemon Docker Unix local attesté et l’approbateur indépendant de la chaîne de fabrication contrôlent le passage.
Déplier ou replier les détails de sécurité et de preuve
Sécurité, preuve et décision
Le statut de preuve reste visible quel que soit le profil choisi.
| Sécurité et identité | Preuve et sources | Blockers | Définitions |
|---|---|---|---|
| Archive OCI fermée, digests, pin d’image, Docker Unix local attesté et keeper inerte sans réseau. | Niveau de preuve: PROUVÉ localement: validation d’une archive OCI à membres fermés, digests de blobs et identité d’image, liaison au digest des sources de reprise, publication atomique, nettoyage des résidus de staging, retrait du tag de build et keeper arrêté avec network=none, entrypoint /bin/false, utilisateur non-root, rootfs read-only, capacités supprimées et no-new-privileges. Le lab systemd observe zéro tag temporaire après réparation de résidus et la persistance du bundle et du keeper après reboot. PARTIEL: une archive corrompue est rejetée fail-closed et les résidus temporaires sont réparés, mais aucun exercice accepté ne remplace un bundle durable corrompu ni n’atteste une collecte bornée de toutes les images orphelines. NON PROUVÉ: signature externe, SBOM, politique CVE, build hors ligne et runner CI autorisé. L’image du lab a encore utilisé le réseau vers les dépôts Alpine. Verdict NO-GO. NON PROUVÉ: signature externe, SBOM, seuil CVE, build offline et runner CI autorisé. Le lab télécharge encore depuis les dépôts Alpine. NO-GO. Vue d’autorité du domaine · Entrée du catalogue | NO-GO: Release signée, SBOM, décision CVE, provenance des paquets, build offline, repair drill du bundle durable, inventaire avant/après des images et attestation CI indépendante. | Consulter les définitions de cette fiche |
| Données et souveraineté UE | Le composant manipule des images OCI, digests et labels, conservés sur la machine locale. Le build du lab a encore téléchargé depuis les dépôts Alpine, un tiers non maîtrisé. Aucune distribution ni installation production n’existe. Signature externe, SBOM et seuil CVE non prouvés; aucune résidence de données n’est démontrée. | ||