Skip to content

Final Product Roadmap

Jump to bottom
CYPT71 edited this page Aug 21, 2026 · 2 revisions

v6 — Graal : Platform Factory

Vision

Platform Factory fournit une interface unifiée permettant de transformer une source applicative, une image OCI ou une machine virtuelle historique en charge de travail sécurisée, reproductible et déployable.

L’expérience principale repose sur trois commandes :

pf init <source>
pf build
pf publish <target>

Le nom officiel du produit est :

Platform Factory

Le nom du binaire installé est :

platform-factory

L’alias CLI recommandé est :

pf

Principes non négociables

  • Conserver la génération OCI indépendante de Docker, Podman et BuildKit.
  • Ne pas utiliser de moteur de build tiers dans le chemin principal.
  • Ne pas utiliser de moteur de virtualisation tiers dans le chemin MicroVM natif.
  • Ne pas déléguer silencieusement une capacité critique à une commande externe.
  • Valider toutes les entrées non fiables.
  • Produire des résultats reproductibles et adressés par contenu.
  • Relier chaque preuve au digest exact de l’artefact et au SHA du code testé.
  • Conserver une seule source de vérité pour le cycle de vie des workloads.
  • Expliquer les décisions automatiques avant toute mutation.
  • Refuser explicitement les fonctionnalités dont la sémantique n’est pas prise en charge.
  • Préserver les modes conteneur, MicroVM OCI et MicroVM sans OCI.
  • Ne jamais modifier une image disque source par défaut.

Architecture cible

Source
  │
  ├── dépôt local ou Git
  ├── projet applicatif
  ├── archive
  ├── image ou layout OCI
  └── disque de VM
          │
          ▼
       pf init
          │
          ▼
Analyse, inventaire et plan de transformation
          │
          ▼
       pf build
          │
          ▼
OCI / boot bundle / MicroVM
SBOM / provenance / signature
          │
          ▼
      pf publish
          │
   ┌────────────────┼─────────┬─────────┐
   ▼                ▼         ▼         ▼
Registry           Podman   Docker   Kubernetes
                     │        │         │
                     └──── MicroVM ─────┘

v6.0 — Fondation de la CLI

Identité et distribution

  • Créer le binaire platform-factory.
  • Fournir l’alias officiel pf.
  • Ajouter pf version.
  • Ajouter pf help.
  • Ajouter la complétion Bash.
  • Ajouter la complétion Zsh.
  • Ajouter la complétion Fish.
  • Ajouter la complétion PowerShell.
  • Fournir des paquets Linux.
  • Fournir un paquet macOS.
  • Fournir un paquet Windows.
  • Documenter la politique de compatibilité CLI.
  • Stabiliser les codes de sortie.
  • Stabiliser le format de sortie machine.
  • Propager un identifiant de trace sur toute opération.

Commandes principales

  • Implémenter pf init.
  • Implémenter pf build.
  • Implémenter pf publish.
  • Ajouter --yes.
  • Ajouter --dry-run.
  • Ajouter --json.
  • Ajouter --quiet.
  • Ajouter --verbose.
  • Ajouter --trace-id.
  • Ajouter --config.
  • Ajouter --profile.
  • Garantir un comportement homogène entre les commandes.

Réutilisation du moteur existant

  • Utiliser les bibliothèques internes existantes sans recopier leur logique dans la CLI.
  • Relier pf build au pipeline et au constructeur OCI existants.
  • Relier pf publish au Registry natif existant.
  • Relier les preuves au moteur natif de SBOM, provenance et signature.
  • Relier les workloads MicroVM au même superviseur que les façades OCI.
  • Ne pas créer une seconde base d’état propre à Platform Factory.

v6.1 — pf init

Contrat utilisateur

pf init <source>

La commande initialise un espace Platform Factory à partir d’une source existante ou d’un nouveau projet.

Exemples :

pf init .
pf init ./application
pf init ./legacy.qcow2
pf init ./server.vmdk
pf init oci://registry.example.com/team/app:1.0
pf init git://example.com/team/application.git

Initialisation du projet

  • Détecter la racine du projet.
  • Initialiser un dépôt Git lorsqu’aucun dépôt n’existe.
  • Refuser d’écraser un dépôt Git existant.
  • Générer un .gitignore.
  • Générer platform-factory.yaml.
  • Générer platform-factory.lock.
  • Générer le répertoire .pf/.
  • Générer le répertoire policies/.
  • Générer le répertoire deploy/.
  • Générer le répertoire dist/.
  • Générer le répertoire reports/.
  • Conserver les fichiers utilisateur existants.
  • Produire un plan avant toute écriture.
  • Rendre toutes les mutations atomiques.
  • Permettre l’annulation sans laisser de projet partiellement initialisé.

Compatibilité avec les configurations existantes

  • Découvrir les fichiers .config_image.yaml.
  • Découvrir les fichiers .config_image.yml.
  • Découvrir les fichiers .config_img.yaml.
  • Découvrir les fichiers .config_img.yml.
  • Découvrir leurs variantes JSON.
  • Importer leur contenu vers platform-factory.yaml.
  • Conserver une trace de migration.
  • Refuser les champs inconnus.
  • Expliquer toute valeur modifiée ou normalisée.
  • Maintenir la compatibilité ascendante des schémas.

Sources applicatives

  • Supporter un répertoire local.
  • Supporter un dépôt Git local.
  • Supporter une archive tar.
  • Supporter une archive tar compressée.
  • Supporter un layout OCI.
  • Supporter une archive OCI.
  • Supporter une archive Docker Save.
  • Supporter une référence Registry OCI.
  • Supporter plusieurs sources dans un même projet.
  • Vérifier les digests fournis.
  • Épingler les sources distantes.
  • Refuser les redirections ou références non conformes à la politique.

Détection des écosystèmes

  • Détecter Go.
  • Détecter Node.js.
  • Détecter Python.
  • Détecter Java.
  • Détecter .NET.
  • Détecter Rust.
  • Détecter Ruby.
  • Détecter PHP.
  • Supporter les commandes personnalisées.
  • Détecter les projets multi-écosystèmes.
  • Résoudre ou signaler les ambiguïtés.
  • Produire un inventaire de gel SHA-256.
  • Identifier toolchains, dépendances, application et métadonnées.
  • Préparer un DAG initial pour pf build.

v6.2 — Import de VM legacy

Formats de disques

  • Détecter RAW.
  • Détecter QCOW2.
  • Détecter VMDK.
  • Détecter VHD.
  • Détecter VHDX.
  • Détecter ISO.
  • Détecter les formats non supportés sans tenter de les monter.
  • Valider les en-têtes et tailles avant lecture approfondie.
  • Borner le temps, la mémoire et le nombre d’objets analysés.
  • Tester les images tronquées, cycliques et malformées.

Lecture sécurisée

  • Ouvrir les disques en lecture seule.
  • Refuser l’écriture implicite.
  • Ne pas utiliser un montage hôte non confiné.
  • Isoler le parseur de disque.
  • Borner les offsets et tailles.
  • Détecter les chevauchements de partitions.
  • Détecter les tables de partitions corrompues.
  • Ne jamais suivre un chemin hors de l’image analysée.
  • Journaliser les décisions sans exposer de secrets.

Partitions et volumes

  • Supporter MBR.
  • Supporter GPT.
  • Détecter les partitions étendues.
  • Détecter LVM.
  • Détecter les volumes chiffrés.
  • Signaler les volumes nécessitant une clé.
  • Supporter plusieurs disques associés à une VM.
  • Identifier le disque racine probable.
  • Identifier les volumes de données.
  • Détecter les volumes swap.
  • Produire une cartographie stable des volumes.

Systèmes de fichiers

  • Lire ext2.
  • Lire ext3.
  • Lire ext4.
  • Lire XFS.
  • Lire Btrfs.
  • Lire FAT.
  • Lire NTFS en lecture seule.
  • Détecter les filesystems non supportés.
  • Détecter les métadonnées incohérentes.
  • Limiter le nombre de fichiers inventoriés.
  • Limiter la taille totale logique analysée.
  • Préserver les informations de permissions et propriétaires.
  • Préserver ou signaler les ACL et attributs étendus.

Détection du système

  • Identifier la distribution Linux.
  • Identifier la version.
  • Identifier l’architecture CPU.
  • Identifier le noyau attendu.
  • Identifier systemd.
  • Identifier SysV init.
  • Identifier OpenRC.
  • Identifier BusyBox init.
  • Identifier les unités de service.
  • Identifier les scripts de démarrage.
  • Identifier les tâches cron.
  • Identifier les timers systemd.
  • Identifier les utilisateurs et groupes.
  • Identifier les services réseau.
  • Identifier les ports probables.
  • Identifier les mounts et volumes persistants.

Inventaire applicatif

  • Détecter les binaires exécutables.
  • Détecter les dépendances ELF.
  • Détecter les interpréteurs.
  • Détecter les runtimes applicatifs.
  • Détecter les bibliothèques partagées.
  • Détecter les fichiers de configuration.
  • Détecter les certificats.
  • Détecter les secrets probables sans révéler leur contenu.
  • Détecter les sockets Unix.
  • Détecter les périphériques requis.
  • Détecter les modules noyau requis.
  • Détecter les dépendances à /proc, /sys et /dev.
  • Identifier le processus principal probable.
  • Produire un niveau de confiance pour chaque détection.

Rapport d’analyse

  • Générer reports/discovery.json.
  • Générer un rapport humain lisible.
  • Lister les applications détectées.
  • Lister les services exclus.
  • Lister les données persistantes.
  • Lister les dépendances système.
  • Lister les risques de migration.
  • Lister les éléments nécessitant une intervention humaine.
  • Expliquer les limites de l’analyse.
  • Relier le rapport au digest exact du disque source.

v6.3 — Plan de transformation

Modes d’exécution

Platform Factory doit choisir ou proposer l’un des modes suivants :

container
microvm-oci
microvm-direct
vm-encapsulation
unsupported

Classification

  • Déterminer si l’application peut fonctionner en conteneur standard.
  • Déterminer si elle nécessite un noyau dédié.
  • Déterminer si elle nécessite un périphérique particulier.
  • Déterminer si elle dépend de services système non extractibles.
  • Déterminer si les données peuvent être séparées de l’application.
  • Déterminer si une extraction OCI est sûre.
  • Déterminer si une encapsulation MicroVM est nécessaire.
  • Refuser toute décision automatique dont la confiance est insuffisante.
  • Permettre une stratégie explicitement choisie par l’utilisateur.
  • Ne jamais masquer les incompatibilités.

Rapport de compatibilité

  • Générer reports/compatibility.json.
  • Fournir le mode recommandé.
  • Fournir les modes alternatifs.
  • Fournir un score de confiance.
  • Expliquer chaque décision.
  • Documenter les fonctionnalités perdues.
  • Documenter les différences réseau.
  • Documenter les différences de stockage.
  • Documenter les différences de sécurité.
  • Documenter les écarts de performances attendus.
  • Indiquer les conditions empêchant le déploiement.

Manifeste produit

  • Écrire le plan retenu dans platform-factory.yaml.
  • Épingler les sources dans platform-factory.lock.
  • Épingler les toolchains.
  • Épingler les bases.
  • Épingler les plugins.
  • Épingler le kernel et l’initramfs en mode MicroVM.
  • Calculer une empreinte canonique du plan.
  • Refuser un build lorsque le plan et le lock sont incohérents.

v6.4 — pf build

Contrat utilisateur

pf build

Options principales :

pf build --target container
pf build --target microvm
pf build --target auto
pf build --verify-only
pf build --reproducible
pf build --no-cache

Validation préalable

  • Charger strictement platform-factory.yaml.
  • Charger strictement platform-factory.lock.
  • Vérifier la version des schémas.
  • Vérifier les digests de toutes les sources.
  • Vérifier les signatures exigées.
  • Vérifier les capacités de la plateforme.
  • Vérifier les politiques.
  • Vérifier les budgets de ressources.
  • Vérifier les chemins et références d’artefacts.
  • Vérifier le DAG.
  • Détecter les cycles.
  • Produire le plan résolu avant exécution.

Construction OCI standard

  • Construire un layout OCI déterministe.
  • Construire en streaming.
  • Borner la mémoire.
  • Normaliser les timestamps.
  • Normaliser UID et GID.
  • Normaliser les permissions.
  • Normaliser l’ordre des fichiers.
  • Vérifier les tailles et digests.
  • Vérifier les diff_id.
  • Vérifier les plateformes.
  • Produire amd64.
  • Produire arm64.
  • Produire un index multi-architecture.
  • Supporter plusieurs images et tags.
  • Produire plusieurs couches sémantiques.
  • Séparer toolchain, dépendances, application et métadonnées.
  • Garantir la stabilité octet par octet.
  • Expliquer toute divergence.

Construction depuis un disque legacy

  • Extraire les fichiers applicatifs sélectionnés.
  • Préserver les permissions nécessaires.
  • Préserver les propriétaires nécessaires.
  • Convertir le service principal en configuration OCI.
  • Convertir les variables d’environnement.
  • Convertir le répertoire de travail.
  • Convertir l’utilisateur et les groupes.
  • Convertir les volumes persistants.
  • Convertir les ports détectés.
  • Exclure les fichiers système inutiles.
  • Exclure les secrets par défaut.
  • Produire un rapport des éléments exclus.
  • Vérifier les dépendances dynamiques.
  • Refuser une extraction incomplète non déclarée.
  • Permettre un mode encapsulé lorsque l’extraction n’est pas possible.

Construction MicroVM

  • Produire un rootfs vérifié.
  • Produire un initramfs déterministe.
  • Produire un boot bundle adressé par contenu.
  • Épingler kernel, initramfs et ligne de commande.
  • Configurer l’entrypoint invité.
  • Configurer environnement, cwd, UID, GID et groupes.
  • Produire les métadonnées de volumes.
  • Produire les métadonnées réseau.
  • Vérifier le boot bundle.
  • Tester le démarrage avant publication lorsque la plateforme le permet.
  • Refuser les options OCI non traduites dans le guest.
  • Conserver le chemin MicroVM direct sans OCI.

Pipeline et caches

  • Utiliser le DAG multi-stage existant.
  • Exécuter les branches indépendantes en parallèle.
  • Propager les annulations.
  • Bloquer les descendants d’un stage en échec.
  • Laisser poursuivre les branches indépendantes.
  • Vérifier les digests lors des transferts d’artefacts.
  • Utiliser le CAS natif.
  • Dédupliquer blobs et chunks.
  • Reprendre les transferts interrompus.
  • Gérer leases et garbage collection.
  • Exclure la valeur des secrets des clés de cache.
  • Désactiver la persistance pour les stages sensibles.
  • Nettoyer les écritures partielles après crash ou ENOSPC.

Sécurité du build

  • Isoler chaque stage.
  • Appliquer les politiques réseau.
  • Appliquer CPU, mémoire et PIDs.
  • Appliquer les limites filesystem.
  • Monter les secrets en mémoire.
  • Ne jamais inclure les secrets dans les logs.
  • Ne jamais inclure les secrets dans les caches.
  • Ne jamais inclure les secrets dans les attestations.
  • Refuser les plugins non vérifiés.
  • Confiner fichiers et ressources des plugins.
  • Propager les budgets au pipeline complet.

Preuves natives

  • Générer la SBOM.
  • Générer la provenance.
  • Produire les attestations DSSE.
  • Signer avec Ed25519.
  • Signer avec ECDSA.
  • Vérifier les chaînes X.509.
  • Exécuter deux rebuilds propres.
  • Comparer tous les descripteurs.
  • Produire un rapport de non-reproductibilité.
  • Relier les preuves au digest exact.
  • Refuser un artefact non reproductible selon la politique.
  • Refuser une preuve incohérente avec le journal réel.

Sorties

  • Produire dist/oci-layout/.
  • Produire dist/boot-bundle/ lorsque nécessaire.
  • Produire dist/sbom.json.
  • Produire dist/provenance.json.
  • Produire dist/attestations/.
  • Produire dist/signatures/.
  • Produire reports/build.json.
  • Produire reports/policy.json.
  • Produire reports/reproducibility.json.
  • Produire un résumé humain lisible.

v6.5 — pf publish

Contrat utilisateur

pf publish <target>

Exemples :

pf publish registry
pf publish podman
pf publish docker
pf publish kubernetes
pf publish production

Options principales :

pf publish --target registry
pf publish --target podman
pf publish --target docker
pf publish --target kubernetes
pf publish --push-only
pf publish --deploy-only
pf publish --dry-run
pf publish --wait

Séparation des opérations

  • Séparer conceptuellement la publication d’artefact et le déploiement.
  • Permettre --push-only.
  • Permettre --deploy-only.
  • Refuser --deploy-only lorsque le digest distant attendu est absent.
  • Déployer uniquement par digest immutable.
  • Ne pas déplacer un tag après un refus de politique.
  • Produire un plan complet avant toute mutation.

v6.6 — Publication Registry

  • Utiliser le client Registry OCI natif.
  • Supporter Basic.
  • Supporter Bearer.
  • Reprendre les uploads.
  • Réconcilier l’offset avec le Registry.
  • Supporter le montage cross-repository.
  • Vérifier chaque blob distant.
  • Publier par digest avant de déplacer les tags.
  • Publier la SBOM comme artefact lié.
  • Publier la provenance comme artefact lié.
  • Publier les signatures comme artefacts liés.
  • Publier les attestations comme artefacts liés.
  • Vérifier le digest installé.
  • Nettoyer les sessions persistées.
  • Reprendre correctement après crash.
  • Refuser toute mise à jour de tag si une preuve échoue.

Compatibilité Registry

  • Tester OCI Distribution standard.
  • Tester GHCR.
  • Tester Harbor.
  • Tester Artifactory.
  • Tester ECR.
  • Tester les Registries limitant le montage cross-repository.
  • Tester les réponses Range incohérentes.
  • Tester les interruptions réseau.
  • Tester les blobs déjà présents.
  • Documenter les extensions propres aux fournisseurs.

v6.7 — Déploiement Podman

Conteneur standard

  • Importer silencieusement le layout si nécessaire.
  • Déployer avec le runtime standard par défaut.
  • Supporter plusieurs ports.
  • Supporter volumes et environnement.
  • Relayer stdin, stdout et stderr.
  • Relayer les signaux.
  • Propager le code de sortie.
  • Permettre ps, logs, inspect, stop et rm.

MicroVM secure-oci

  • Installer `platform-factory.
  • Sélectionner le runtime par workload.
  • Faire représenter la vraie MicroVM dans podman ps.
  • Utiliser le superviseur VMM unique.
  • Ne créer aucun conteneur proxy.
  • Finaliser les flags Podman et conmon.
  • Implémenter create.
  • Implémenter start.
  • Implémenter state.
  • Implémenter kill.
  • Implémenter delete.
  • Implémenter wait.
  • Implémenter les logs persistants.
  • Relayer exactement stdin, stdout et stderr.
  • Relayer les signaux jusqu’au guest.
  • Propager exactement le code de sortie invité.
  • Remplacer le PID réutilisable par pidfd.
  • Remplacer le marqueur .start par un socket Unix READY/ACK.
  • Nettoyer les ressources après crash.
  • Vérifier l’absence de PID orphelin.
  • Vérifier l’absence de descripteur KVM orphelin.
  • Vérifier l’absence d’état runtime orphelin.

v6.8 — Déploiement Docker et containerd

Shim containerd

  • Implémenter un shim containerd v2.
  • Partager le superviseur MicroVM existant.
  • Partager l’identité du workload.
  • Partager le state store.
  • Ne pas créer une seconde source de vérité.
  • Implémenter create/start/state/kill/delete.
  • Implémenter exec lorsque pris en charge.
  • Relayer stdin, stdout et stderr.
  • Relayer les signaux.
  • Propager le code de sortie.
  • Gérer les événements containerd.
  • Gérer la reconnexion après redémarrage du daemon.
  • Nettoyer après crash du shim.
  • Nettoyer après crash du guest.
  • Nettoyer après crash du VMM.

Docker

  • Installer la configuration du runtime sans remplacer le runtime par défaut.
  • Permettre une sélection explicite du runtime.
  • Afficher la vraie charge MicroVM dans Docker.
  • Faire fonctionner docker ps.
  • Faire fonctionner docker logs.
  • Faire fonctionner docker inspect.
  • Faire fonctionner docker stop.
  • Faire fonctionner docker rm.
  • Faire fonctionner docker wait.
  • Documenter les limites de sélection runtime selon la version de Docker.
  • Tester le cycle complet sur un daemon réel.

Nerdctl

  • Supporter nerdctl via containerd.
  • Faire fonctionner nerdctl ps.
  • Faire fonctionner nerdctl logs.
  • Faire fonctionner nerdctl stop.
  • Faire fonctionner nerdctl rm.
  • Tester le cycle de vie complet.

v6.9 — Déploiement Kubernetes

Runtime

  • Fournir une RuntimeClass secure-oci.
  • Installer le shim containerd sur les nœuds compatibles.
  • Détecter les capacités KVM, Hyper-V ou Virtualization.framework.
  • Ajouter des labels de nœuds.
  • Ajouter les tolérances nécessaires.
  • Fournir un installateur idempotent.
  • Fournir une procédure de rollback.

Génération des manifests

  • Générer un Deployment.
  • Générer un StatefulSet.
  • Générer un DaemonSet.
  • Générer un Job.
  • Générer un CronJob.
  • Générer un Service.
  • Générer un Ingress.
  • Générer les PersistentVolumeClaim.
  • Générer les ConfigMap.
  • Générer les références aux Secret sans en copier les valeurs.
  • Générer la RuntimeClass.
  • Déployer uniquement par digest.
  • Ajouter les probes compatibles avec le guest.
  • Ajouter les ressources demandées.
  • Ajouter les politiques de sécurité.
  • Produire des manifests déterministes.

Cycle de vie

  • Faire représenter le vrai workload MicroVM dans Kubernetes.
  • Relayer les logs.
  • Relayer les signaux de terminaison.
  • Propager le code de sortie.
  • Supporter les redémarrages.
  • Supporter la suppression forcée.
  • Supporter le drainage de nœud.
  • Supporter les timeouts de terminaison.
  • Ne laisser aucune MicroVM après suppression du Pod.
  • Ne laisser aucun port ou volume orphelin.

Déploiements progressifs

  • Supporter rollout.
  • Supporter rollback.
  • Supporter blue/green.
  • Supporter canary.
  • Vérifier les preuves avant admission.
  • Bloquer le déploiement après refus de politique.
  • Relier le statut du déploiement au digest exact.

v6.10 — Réseau et stockage MicroVM

Réseau

  • Implémenter un périphérique réseau natif minimal.
  • Supporter TAP lorsque disponible.
  • Supporter un mode rootless.
  • Supporter TCP.
  • Supporter UDP.
  • Supporter plusieurs ports.
  • Supporter les redirections entrantes.
  • Supporter les connexions sortantes selon la politique.
  • Fournir un DNS détenu par le projet.
  • Isoler le réseau hôte par défaut.
  • Nettoyer les interfaces après crash.
  • Nettoyer les règles de redirection après crash.

Stockage

  • Implémenter le disque virtio minimal.
  • Supporter un rootfs en lecture seule.
  • Supporter les volumes en lecture-écriture.
  • Supporter les volumes temporaires.
  • Vérifier les digests des volumes immuables.
  • Empêcher les traversées de chemins.
  • Gérer les limites de taille.
  • Gérer le flush et l’arrêt propre.
  • Nettoyer les snapshots temporaires.
  • Tester les corruptions et interruptions d’entrée/sortie.

v6.11 — Agent invité

  • Implémenter un agent invité minimal détenu par le projet.
  • Définir un protocole versionné.
  • Authentifier le canal hôte-invité.
  • Transporter les commandes.
  • Transporter les signaux.
  • Transporter l’état.
  • Transporter stdout.
  • Transporter stderr.
  • Transporter le code de sortie.
  • Supporter l’arrêt propre.
  • Supporter les heartbeats.
  • Détecter un guest bloqué.
  • Borner les messages.
  • Refuser les versions incompatibles.
  • Tester les messages malformés.
  • Tester les replays.
  • Tester la perte du canal.

v6.12 — Observabilité

Commandes

  • Ajouter pf status.
  • Ajouter pf logs.
  • Ajouter pf inspect.
  • Ajouter pf events.
  • Ajouter pf doctor.
  • Ajouter pf explain.
  • Ajouter pf rollback.

Données observables

  • Journaux structurés.
  • Identifiant de trace de bout en bout.
  • Métriques de build.
  • Métriques de publication.
  • Métriques de déploiement.
  • Métriques VMM.
  • Événements de cycle de vie.
  • Codes de sortie.
  • Raisons de décision de politique.
  • Raisons de sélection container/MicroVM.
  • Diagnostics actionnables.
  • Redaction automatique des secrets.

pf doctor

  • Vérifier Git.
  • Vérifier l’accès Registry.
  • Vérifier Docker.
  • Vérifier Podman.
  • Vérifier containerd.
  • Vérifier Kubernetes.
  • Vérifier /dev/kvm.
  • Vérifier les extensions KVM.
  • Vérifier Hyper-V.
  • Vérifier Virtualization.framework.
  • Vérifier les permissions.
  • Vérifier les cgroups.
  • Vérifier les namespaces.
  • Vérifier les politiques.
  • Produire des corrections proposées sans les appliquer silencieusement.

v6.13 — Déploiement distribué

  • Relier pf build au control plane distribué.
  • Relier les vrais stages pipeline aux leases.
  • Persister l’état du scheduler.
  • Séparer scheduler et control plane.
  • Authentifier chaque rôle.
  • Ajouter le fencing par incarnation.
  • Ajouter l’annulation distante.
  • Reprendre un build après perte d’un worker.
  • Planifier selon plateforme.
  • Planifier selon capacités.
  • Planifier selon charge.
  • Planifier selon localité du cache.
  • Exécuter amd64 et arm64 en parallèle.
  • Ajouter quotas.
  • Ajouter priorités.
  • Ajouter fairness.
  • Ajouter limites par tenant.
  • Répliquer le CAS.
  • Vérifier chaque blob répliqué.
  • Signer les résultats avec l’identité du worker.
  • Rendre le journal append-only.
  • Tester partitions, replay, duplication et corruption.

v6.14 — Sécurité et stabilisation

VMM

  • Appliquer seccomp au VMM.
  • Appliquer les namespaces.
  • Appliquer les cgroups.
  • Abandonner les privilèges.
  • Borner vCPU et mémoire.
  • Borner les périphériques.
  • Protéger le state store.
  • Tester le crash du VMM.
  • Tester le crash du guest.
  • Tester le timeout de boot.
  • Tester la récupération d’état.
  • Tester les noyaux et initramfs hostiles.

CLI et API

  • Stabiliser le schéma platform-factory.yaml.
  • Stabiliser le schéma platform-factory.lock.
  • Publier une politique de compatibilité.
  • Publier une politique de dépréciation.
  • Fournir les migrations automatisées.
  • Fournir une suite de conformance publique.
  • Fournir une suite de conformance des backends.
  • Fournir une suite de conformance des cibles de publication.
  • Garantir la compatibilité des formats de sortie machine.

Audit externe

  • Obtenir une revue sécurité indépendante.
  • Auditer les parseurs de disque.
  • Auditer le Registry.
  • Auditer les plugins.
  • Auditer le VMM.
  • Auditer l’agent invité.
  • Exécuter des tests de pénétration.
  • Publier les risques résiduels.
  • Publier les procédures de réponse aux incidents.

Exploitation

  • Publier des SLO.
  • Publier les runbooks.
  • Publier les procédures de rollback.
  • Publier les procédures de récupération.
  • Tester l’installation par un opérateur indépendant.
  • Tester le rollback par un opérateur indépendant.
  • Tester une montée de version sans perte d’état.
  • Tester une montée de version sans perte de cache.
  • Tester la compatibilité avec des workloads existants.

Critères de sortie du Graal

Parcours projet moderne

Le scénario suivant doit fonctionner sans édition manuelle :

pf init ./application
pf build
pf publish kubernetes

Le système doit :

  • détecter l’écosystème ;
  • produire un plan explicable ;
  • construire un OCI reproductible ;
  • produire SBOM, provenance et signatures ;
  • publier par digest ;
  • générer les manifests ;
  • déployer la charge ;
  • exposer logs, état et code de sortie ;
  • permettre rollout et rollback.

Parcours legacy

Le scénario suivant doit fonctionner sans modification du disque source :

pf init ./legacy-server.qcow2
pf build
pf publish kubernetes

Le système doit :

  • identifier le format de disque ;
  • analyser partitions et filesystems ;
  • identifier le système d’exploitation ;
  • inventorier services et dépendances ;
  • séparer application et données ;
  • choisir container, MicroVM ou encapsulation ;
  • justifier cette décision ;
  • produire un artefact reproductible ;
  • publier les preuves ;
  • déployer avec le runtime approprié ;
  • administrer honnêtement le véritable workload.

Parcours multi-runtime

Le même artefact doit pouvoir être utilisé selon la cible :

pf publish podman
pf publish docker
pf publish kubernetes

Pour une charge MicroVM :

  • chaque moteur doit afficher la vraie MicroVM ;
  • chaque moteur doit utiliser la même identité ;
  • chaque moteur doit utiliser le même superviseur ;
  • aucun moteur ne doit utiliser de conteneur proxy ;
  • ps, logs, inspect, stop, wait et rm doivent fonctionner ;
  • signaux et codes de sortie doivent être exacts ;
  • aucune ressource ne doit rester après suppression.

Résilience

  • Un crash du builder ne laisse aucun blob partiel installé.
  • Un crash du Registry ne déplace aucun tag prématurément.
  • Un crash du runtime ne laisse aucune MicroVM orpheline.
  • Un crash du guest est visible par la plateforme.
  • Un crash du worker permet la reprise du build.
  • Une partition réseau ne provoque ni double publication ni double completion.
  • Une image altérée est refusée.
  • Une preuve ne correspondant pas au digest est refusée.
  • Une source legacy malformée ne compromet pas l’hôte.

Définition de « terminé »

Une case Graal ne peut être cochée que si :

  • l’implémentation existe dans le dépôt ;
  • le chemin est accessible via platform-factory ou pf ;
  • les entrées non fiables sont validées ;
  • des tests positifs existent ;
  • des tests négatifs existent ;
  • les limites sont documentées ;
  • les risques résiduels sont documentés ;
  • la CI exécute le chemin réel ;
  • aucune commande externe interdite ne fournit la capacité ;
  • les preuves sont liées au SHA testé ;
  • le comportement est couvert par la conformance publique ;
  • le rollback ou nettoyage est testé lorsqu’une mutation est impliquée.

Ordre d’exécution recommandé

Priorité 0 — Fermer v4

  • Finaliser Podman E2E.
  • Remplacer PID et marqueur .start.
  • Implémenter l’agent invité.
  • Implémenter réseau et stockage virtio minimaux.
  • Relayer exactement entrées, sorties, signaux et codes de sortie.
  • Remplacer le chemin QEMU de production sur Linux.
  • Ajouter le shim containerd v2.
  • Ajouter la RuntimeClass Kubernetes.

Priorité 1 — Façade Platform Factory

  • Créer platform-factory.
  • Créer l’alias pf.
  • Implémenter pf init pour les projets modernes.
  • Relier pf build au moteur existant.
  • Relier pf publish au Registry et aux runtimes existants.
  • Stabiliser platform-factory.yaml.
  • Stabiliser platform-factory.lock.

Priorité 2 — Import legacy en inventaire

  • Détecter les formats de disques.
  • Lire partitions et filesystems en lecture seule.
  • Inventorier OS, services, utilisateurs, ports et données.
  • Produire un rapport de compatibilité.
  • Ne réaliser aucune conversion automatique à ce stade.

Priorité 3 — Conversion legacy vers OCI

  • Extraire une application simple.
  • Convertir son service principal.
  • Construire un OCI reproductible.
  • Vérifier son exécution en conteneur.
  • Basculer vers MicroVM lorsque nécessaire.
  • Ajouter un corpus public de VM de test.

Priorité 4 — Déploiement multi-cible

  • Stabiliser Podman.
  • Stabiliser Docker.
  • Stabiliser containerd.
  • Stabiliser Kubernetes.
  • Ajouter rollout et rollback.
  • Ajouter les suites de conformance multi-moteur.

Priorité 5 — Production distribuée

  • Persister le control plane.
  • Relier les vrais builds aux workers.
  • Répliquer le CAS.
  • Ajouter HA, quotas et audit.
  • Valider les mises à niveau et récupérations.

Démonstration finale

Le Graal est atteint lorsque cette séquence fonctionne réellement :

pf init legacy-server.qcow2
pf build
pf publish kubernetes

et que Platform Factory :

  1. analyse la source sans la modifier ;
  2. identifie le workload et ses dépendances ;
  3. choisit entre conteneur, MicroVM OCI ou encapsulation ;
  4. produit un artefact déterministe ;
  5. génère SBOM, provenance, attestations et signatures ;
  6. applique les politiques ;
  7. publie l’artefact par digest ;
  8. déploie le véritable workload ;
  9. expose son cycle de vie complet ;
  10. garantit qu’aucune ressource n’est laissée orpheline.

À ce stade, Platform Factory n’est plus une façade cosmétique posée sur secure-oci. Elle devient le produit qui orchestre proprement les capacités construites de v1 à v5.

© 2026 CYPT71

platform-factory

Home

Core

CI/CD

Running an image

Operating

Clone this wiki locally