Je viens de passer plusieurs jours à poncer Incus OS, à en éplucher toutes les fonctionnalités une par une. Pas de la curiosité gratuite : j'avais un objectif précis en tête, monter un cloud privé complet. Et j'y suis arrivé. Un cluster, du stockage Ceph, des réseaux virtuels OVN, des Security Groups, du multi-tenant avec quotas et accès scopés. Un vrai IaaS souverain, façon AWS en réduction, sur mes propres machines. Toute la recette est dans la section Incus, du serveur nu au multi-tenant.
Sauf qu'un cloud privé vide ne sert à rien. Une fois le socle debout, la vraie question arrive : qu'est-ce qu'on met dessus ? Pour moi la réponse est évidente. Je veux une usine logicielle, la chaîne qui transforme du code en artefacts déployables, mais sécurisée de bout en bout, multi-tenant et multi-utilisateur. Le genre de plateforme que je passe mes journées à durcir pour d'autres.
Ce billet n'est pas un tutoriel de déploiement. C'est le plan que j'ai arrêté, et surtout un choix que j'assume : je ne l'ai pas bâtie sur Kubernetes. Voici pourquoi, et à quoi ressemble le blueprint.
Ce que j'appelle une usine logicielle
Une usine logicielle (software factory) est une chaîne de production qui va du code source à l'artefact déployable, en passant par des maillons standardisés : gestion du code, build, tests, packaging, distribution. La rendre sécurisée, c'est faire en sorte que chaque maillon soit isolé, tracé et prouvable. On doit pouvoir répondre après coup à une question simple : qui a produit cet artefact, à partir de quel commit, avec quelles dépendances, et comment le vérifier.
Ce modèle n'a rien d'une lubie personnelle. La CNCF et l'OpenSSF ont publié une Secure Software Factory Reference Architecture qui découpe la chaîne en étages, source, build, vérification des matériaux, dépôt d'artefacts, distribution, admission, avec de la signature et des attestations à chaque étape. Côté défense, la DoD Platform One et sa plateforme Big Bang appliquent les mêmes principes avec une forge maison, un catalogue d'images durcies et un modèle zero-trust. Et le cadre SLSA vient grader la robustesse du build. Je m'appuie sur ces références, pas sur mon intuition.
Pourquoi pas Kubernetes
Le réflexe du moment, c'est de tout empiler dans Kubernetes. Big Bang fait exactement ça. Je l'assume franchement : pour un homelab et pour beaucoup de PME, c'est un marteau-pilon. On se retrouve à maintenir un plan de contrôle entier, ses opérateurs et sa dette opérationnelle, avant même d'avoir produit le premier artefact signé.
Ce que je veux d'abord, c'est cloisonner des charges qui ne se font pas confiance. Un runner de build exécute du code que je n'ai pas écrit ni vérifié : c'est la zone la plus dangereuse de toute la chaîne. Un coffre à secrets garde mes clés de signature : c'est le trésor. Les faire cohabiter dans le même espace est une faute d'architecture. Incus me donne cette isolation comme brique de base : ses projects séparent instances, réseaux et volumes par tenant, et je mélange conteneurs et VM sur le même cluster sans imposer d'orchestrateur unique.
Résultat, Kubernetes ne disparaît pas, il change de statut. Il devient une charge parmi d'autres, déployée dans son propre tenant quand une application en a réellement besoin, pas le socle obligatoire de toute la plateforme. Cette inversion, c'est tout le pari du blueprint.
Un tenant par étage
Le principe zero-trust dit qu'aucun étage ne fait confiance à un autre par défaut. Je le traduis directement en objets Incus : un project par étage sensible, un VPC OVN par project, et des ACL qui n'ouvrent que les flux strictement nécessaires. C'est exactement la segmentation que j'ai déjà validée sur une application trois tiers, appliquée cette fois à l'usine entière.
Chaque étage s'appuie sur une brique 100% libre, déjà documentée sur le site. La stack que j'ai retenue est volontairement souveraine :
- Source : la forge Forgejo, dépôts, revue et CI intégrée.
- Build : des runners éphémères pilotés par GARM, une VM ou un conteneur jetable par job, détruit ensuite. C'est ici que je m'inspire le plus d'un projet existant, StepSecurity Harden-Runner, la brique qui a justement repéré l'attaque tj-actions/changed-files en 2025. Le hic, c'est qu'elle est couplée à GitHub Actions. Alors je ne l'ajoute pas, je reproduis son principe sur mon socle. Son filtrage egress en liste blanche, je le pose au niveau réseau avec les ACL OVN du tenant build : le runner ne sort que vers la forge, le firewall de dépendances et le registre, rien d'autre. Sa détection runtime des process et connexions anormaux, je la confie à un capteur eBPF dans le runner. Même défense, rebâtie souveraine sur Incus. Le guide durcir l'environnement de build détaille les réflexes.
- Matériaux : un Artifact Firewall qui filtre les dépendances entrantes avant qu'elles ne contaminent quoi que ce soit.
- Artefacts : Pulp, avec signature Cosign. Je le préfère nettement à Harbor sur le terrain souverain : 100% open source, sans zone grise de licence.
- Preuves : SBOM avec Syft, scan avec Trivy ou Grype, signature et provenance avec Sigstore et SLSA.
- Secrets et identités : le coffre OpenBao et un annuaire pour les comptes.
Aucune de ces briques n'est à réinventer. Le vrai travail, c'est de les assembler proprement, chacune dans son périmètre, avec les bons flux et rien de plus.
Le chemin d'un commit
Pour sentir comment les étages coopèrent, je suis un commit de bout en bout. Chaque étape franchit une frontière de tenant et ajoute une preuve vérifiable.
Le développeur pousse sur Forgejo. Un webhook déclenche le pipeline, et GARM provisionne un runner jetable sur Incus, utilisé une seule fois. Ce runner tire ses dépendances à travers l'Artifact Firewall, qui bloque ou met en quarantaine les versions douteuses. Le code compile dans cet espace isolé, puis on génère le SBOM, on scanne, on signe l'artefact et on émet une attestation de provenance. Le livrable signé part alors dans Pulp, et au moment du déploiement, une policy refuse tout artefact non signé ou non conforme.
À l'arrivée, chaque artefact déployé porte une traçabilité complète : quel commit, quel runner, quelles dépendances, quelle signature. C'est précisément ce que réclame le CRA et ce que grade SLSA. Et surtout, le runner compromis d'un tenant ne peut jamais atteindre le coffre à secrets d'un autre : la frontière est posée dans le réseau, pas seulement dans les têtes.
Ce qui est fait, ce qui reste
Je préfère être honnête sur l'état réel. Le socle cloud privé, je l'ai monté et testé pour de bon : cluster Incus, stockage, réseaux OVN, ACL, multi-tenant, quotas appliqués, credentials scopés. Ça, c'est solide et c'est documenté.
L'usine par-dessus, c'est le plan que je déroulerai étage par étage, en réutilisant chaque brique dans son tenant. Je ne vous vends pas une plateforme clé en main déjà en production. Je pose une cible cohérente et un chemin pour y arriver, appuyés sur des architectures de référence sérieuses. La nuance compte : un blueprint crédible n'est pas une démo terminée.
Les pièges que j'anticipe
Un plan ne vaut que si l'on connaît ses angles morts. Quatre me préoccupent déjà.
D'abord, la PKI de signature est le vrai trésor. Les clés Cosign doivent vivre dans le coffre, jamais dans un runner, et leur rotation doit être pensée dès le premier jour. Ensuite, un runner qui persiste est un runner compromis en puissance : j'exige des runners réellement éphémères, détruits après chaque job. Troisième point, la segmentation OVN a une limite connue : le default-reject des ACL est buggé côté Incus, donc je pose des règles drop explicites plutôt que de me fier au rejet implicite. Enfin, il manque encore un portail self-service : Incus se pilote en ligne de commande et par API, et un cockpit multi-tenant à la manière d'un cloud public reste une couche à construire au-dessus. C'est le chaînon que je garde en ligne de mire.
À retenir
- Une usine logicielle sécurisée isole, trace et prouve chaque maillon, du code à l'artefact déployé.
- Le modèle vient de références solides : Secure Software Factory de la CNCF, Platform One / Big Bang, SLSA.
- J'ai choisi Incus comme socle plutôt que le tout-Kubernetes : le multi-tenant natif me donne un tenant par étage, conteneurs et VM mélangés.
- La stack est 100% libre : Forgejo, GARM, Artifact Firewall, Pulp, Cosign, OpenBao, le tout maillé sur les guides existants.
- Le socle cloud privé est fait et testé ; l'usine par-dessus se déroulera étage par étage, sans survendre.
- Les vrais points durs sont la PKI de signature, les runners éphémères et le portail self-service encore absent.