Construire un homelab DevSecOps complet en une journée est impossible. Cette roadmap vous guide phase par phase, de la box FAI jusqu'à un pipeline GitOps avec supply chain sécurisée.
Chaque phase dépend de la précédente. Ne sautez pas d'étapes : un cluster sans réseau propre ou sans gestion d'identité devient un cauchemar à maintenir.
Vue d'ensemble
Section intitulée « Vue d'ensemble »Le tableau ci-dessous se lit de haut en bas : chaque phase consomme ce que la précédente a produit. La colonne Horizon n'est pas une durée de travail mais un ordre de priorité : « Immédiat » signifie que rien d'autre ne peut démarrer tant que ce bloc n'est pas stable. Si vous devez arbitrer, sacrifiez toujours la phase 4 avant la phase 1 : un pare-feu mal posé se paye sur toutes les couches au-dessus, alors qu'une SBOM manquante ne casse aucun service.
| Phase | Horizon | Ce que vous obtenez |
|---|---|---|
| 1. Fondations réseau | Immédiat | OPNsense, LAN propre, accès distant, base DNS |
| 2. Nœud admin de confiance | Court terme | Proxmox admin, authentik, OpenBao |
| 3. Cluster applicatif | Moyen terme | Talos, GitOps, observabilité de base |
| 4. Industrialisation et supply chain | Progressif | Images durcies, signatures, SBOM, politiques |
Phase 1 : Fondations réseau
Section intitulée « Phase 1 : Fondations réseau »Objectif : disposer d'une base réseau propre, administrable à distance, avant d'introduire la segmentation avancée.
Ce que vous installez
Section intitulée « Ce que vous installez »L'ordre des lignes compte : OPNsense doit fonctionner avant tout le reste, parce qu'il porte à la fois le routage, le filtrage et le DNS local dont dépendront ensuite les certificats et les noms de service. Le switch manageable n'apporte rien tant que le LAN est plat, mais l'acheter maintenant évite de tout recâbler quand vous introduirez les VLANs. Proxmox VE arrive en dernier : il n'est utile qu'une fois que vous savez joindre le réseau d'administration à distance.
| Composant | Rôle | Guide |
|---|---|---|
| OPNsense | Pare-feu, routeur, DNS | Installation |
| Tailscale | Accès distant sans port exposé | OPNsense + Tailscale |
| Switch manageable | Prépare les futurs VLANs | Administration OPNsense |
| Proxmox VE | Hyperviseur pour le nœud admin | Installation |
Segmentation prévue ensuite
Section intitulée « Segmentation prévue ensuite »Une fois le LAN principal stabilisé, l'étape suivante consistera à introduire des VLANs distincts pour l'administration, les services et éventuellement l'IoT.
Les subnets ci-dessous sont une cible, pas une configuration déjà en place. Le
plan d'adressage change de plage (10.0.x.0/24 au lieu de 192.168.10.0/24)
pour que la coexistence des deux réseaux pendant la migration ne provoque aucun
recouvrement. Le réseau IOT est le seul qui doive être totalement isolé,
sans route vers MGMT : c'est là que se trouvent les équipements que vous ne
pouvez ni patcher ni auditer.
| Réseau cible | Subnet envisagé | Usage |
|---|---|---|
| MGMT | 10.0.10.0/24 | Administration |
| SERVERS | 10.0.20.0/24 | VMs et conteneurs |
| IOT | 10.0.30.0/24 | Objets connectés (isolés) |
Checklist Phase 1
Section intitulée « Checklist Phase 1 »Cette liste sert de porte de sortie : tant qu'une case reste vide, la phase 2 ne démarre pas. Le point le plus souvent bâclé est la validation de l'accès distant : cochez-le seulement après avoir coupé le Wi-Fi local et vérifié que vous joignez toujours l'interface OPNsense via Tailscale. Un accès distant « qui marche depuis le canapé » ne prouve rien.
- OPNsense installé et accessible
- LAN principal en
192.168.10.0/24fonctionnel - Tailscale connecté et accès distant validé
- DNS local prêt à être enrichi
- Proxmox admin accessible sur le LAN
- Plan de segmentation future identifié
Guide complet : OPNsense + Tailscale
Phase 2 : Nœud admin de confiance
Section intitulée « Phase 2 : Nœud admin de confiance »Objectif : poser une source d'identité et de secrets indépendante du futur cluster.
Ce que vous installez
Section intitulée « Ce que vous installez »Ces trois briques répondent chacune à une question différente : authentik répond à « qui es-tu », OpenBao à « quel secret as-tu le droit de lire », et step-ca à « ce certificat est-il légitime ». La dernière colonne signale que step-ca n'a pas encore de guide dédié sur le site : la PKI interne peut attendre que le cluster existe, alors que le SSO et le coffre de secrets doivent le précéder.
| Composant | Rôle | Guide |
|---|---|---|
| authentik | SSO, OIDC, gestion utilisateurs | Installation |
| OpenBao | Secrets, credentials dynamiques | Installation |
| step-ca | PKI interne, certificats X.509 | Étape suivante |
Pourquoi sur un nœud séparé ?
Section intitulée « Pourquoi sur un nœud séparé ? »Ces services authentifient et distribuent les secrets au cluster. Si le cluster tombe, vous avez toujours accès à l'identité et aux secrets pour le reconstruire.
Intégrations à prévoir ensuite
Section intitulée « Intégrations à prévoir ensuite »Ce tableau se lit comme une file d'attente de travail, pas comme une liste à tout faire d'un coup. La colonne Type indique le protocole de raccordement et donc l'effort réel : les lignes OIDC se configurent en quelques minutes une fois le premier client authentik créé, tandis que le branchement External Secrets vers OpenBao exige d'abord une méthode d'authentification côté cluster. Commencez par Proxmox VE, c'est la cible qui vous fait gagner le plus vite un login unique.
| Source | Cible | Type |
|---|---|---|
| authentik | Proxmox VE | OIDC |
| authentik | Grafana | OIDC |
| authentik | ArgoCD | OIDC |
| OpenBao | Talos (External Secrets) | API |
| step-ca | Traefik (HTTPS) | ACME interne |
Checklist Phase 2
Section intitulée « Checklist Phase 2 »Deux cases de cette liste engagent votre capacité à récupérer le homelab après un incident. Les clés unseal d'OpenBao stockées hors site conditionnent tout redémarrage du coffre : gardées sur la même machine, elles disparaissent avec elle. Le MFA sur le compte admin authentik ferme la porte la plus large, puisque ce compte peut ensuite s'accorder l'accès à tous les services fédérés.
- authentik déployé et accessible
- Compte admin authentik avec MFA activé
- OpenBao initialisé, clés unseal stockées hors site
- DNS local enrichi (
auth.lab.local,vault.lab.local) - Premier utilisateur créé (votre compte perso)
- Sauvegarde des conteneurs/VMs configurée
Guide complet : Nœud admin Proxmox
Phase 3 : Cluster applicatif
Section intitulée « Phase 3 : Cluster applicatif »Objectif : disposer d'un cluster Kubernetes pour vos workloads, piloté en GitOps.
Premiers choix à arbitrer
Section intitulée « Premiers choix à arbitrer »La colonne Complexité mesure le coût d'apprentissage initial, pas la robustesse du résultat. Talos Linux demande plus d'efforts au démarrage parce qu'il n'offre ni shell ni gestionnaire de paquets : toute la configuration passe par une API et un fichier de machine config. C'est exactement ce qui le rend reproductible ensuite. K3s et K0s vous donnent un cluster en quelques minutes, au prix d'un système hôte classique qu'il faudra durcir et patcher vous-même.
| Distribution | Cas d'usage | Complexité |
|---|---|---|
| Talos Linux | Immutable, sécurisé by design, choix recommandé | Moyenne |
| K3s | Homelab simple, ressources limitées | Faible |
| K0s | Alternative légère à K3s | Faible |
| RKE2 | Plus proche de RKE/Rancher | Moyenne |
Ce que vous installez
Section intitulée « Ce que vous installez »Ces cinq composants s'installent dans l'ordre du tableau, et pas autrement. Talos fournit le plan de contrôle ; ArgoCD devient ensuite le seul chemin d'écriture vers le cluster, ce qui évite la dérive entre ce que contient Git et ce qui tourne réellement. Traefik publie les services, External Secrets évite d'écrire le moindre mot de passe dans un dépôt Git, et le couple Prometheus + Grafana arrive en dernier parce qu'il n'a rien à observer avant que les quatre autres existent.
| Composant | Rôle | Guide |
|---|---|---|
| Talos | Distribution Kubernetes immutable | Installation |
| ArgoCD | GitOps, déploiement continu | GitOps |
| Traefik | Ingress controller, HTTPS | Installation |
| External Secrets | Synchronise les secrets depuis OpenBao | Secrets |
| Prometheus + Grafana | Monitoring et alertes | Installation |
Architecture cluster
Section intitulée « Architecture cluster »Sur le schéma, regardez d'abord les flèches sortantes du cluster : elles pointent toutes vers des services de la phase 2, hébergés hors du cluster. C'est la propriété importante de cette architecture. ArgoCD délègue son authentification à authentik, External Secrets lit ses valeurs dans OpenBao : si le cluster est détruit, les identités et les secrets survivent et permettent de le reconstruire.
Checklist Phase 3
Section intitulée « Checklist Phase 3 »Les deux dernières cases valent toutes les autres réunies : tant qu'une application réelle n'a pas été déployée par ArgoCD et qu'un secret n'a pas transité depuis OpenBao, vous avez un cluster, pas une chaîne de livraison. Validez-les avec une application volontairement triviale ; l'objectif est d'éprouver le chemin, pas la charge.
- Talos installé et fonctionnel (
kubectl get nodes) - ArgoCD déployé, accessible via authentik (OIDC)
- Traefik configuré avec wildcards DNS
*.apps.lab.local - External Secrets connecté à OpenBao
- Prometheus + Grafana opérationnels
- Première app déployée via ArgoCD
- Premiers secrets synchronisés depuis OpenBao
Phase 4 : Industrialisation et supply chain
Section intitulée « Phase 4 : Industrialisation et supply chain »Objectif : garantir l'intégrité et la traçabilité de ce qui tourne sur votre cluster, et industrialiser vos images.
Ce que vous mettez en place
Section intitulée « Ce que vous mettez en place »Ces cinq pratiques forment une chaîne : chacune ne vaut que si la précédente est en place. Signer une image avec Cosign sans politique d'admission côté cluster ne bloque rien, puisque personne ne vérifie la signature au déploiement. Générer une SBOM sans registry privé pour la stocker à côté de l'image la rend introuvable le jour où une CVE tombe. Attaquez donc dans l'ordre du tableau, en vous arrêtant dès que vous n'avez plus le temps : un maillon posé et vérifié vaut mieux que cinq à moitié faits.
| Pratique | Outil | Guide |
|---|---|---|
| Golden images VM | Packer + Ansible | Packer |
| Signature d'images OCI | Cosign + Sigstore | Sigstore |
| SBOM | Syft, Trivy | SBOM |
| Politiques d'admission | Kyverno ou Gatekeeper | Supply chain |
| Registry privé | Harbor ou Zot | Harbor |
Workflow cible
Section intitulée « Workflow cible »Le point à retenir sur ce schéma est le dernier maillon, la vérification par Kyverno au moment de l'admission. Tout ce qui se passe avant, construction, scan, signature, reste déclaratif : rien n'empêche techniquement de déployer une image non signée tant qu'aucun contrôleur ne refuse le Pod. C'est ce contrôle final qui transforme la chaîne en garantie plutôt qu'en intention.
Checklist Phase 4
Section intitulée « Checklist Phase 4 »Cochez la ligne Kyverno en dernier, et seulement après avoir signé au moins
une image : une politique require-signed-images activée trop tôt bloque tous
vos déploiements existants et vous pousse à la désactiver en urgence. Déployez-la
d'abord en mode audit sur un namespace de test, vérifiez les rapports, puis
passez en refus.
- Templates Packer pour VMs (Debian, Ubuntu)
- Pipeline CI qui build, scan, et signe les images
- Registry privé (Harbor) déployé
- Cosign configuré avec votre keyless ou clé privée
- Kyverno installé avec politique "require-signed-images"
- SBOM générés et stockés avec les images
Guides par phase
Section intitulée « Guides par phase »Les liens ci-dessous reprennent l'ordre des quatre phases. Ouvrez-les au moment où vous attaquez la phase correspondante, pas avant : lire le guide Talos alors que le réseau n'est pas segmenté ne sert qu'à accumuler des notes inutilisables.
Phase 1 : Fondations
Section intitulée « Phase 1 : Fondations »Ces trois guides couvrent le socle physique et réseau. Le guide OPNsense + Tailscale est le seul obligatoire pour passer à la suite ; la formation complète et l'installation Proxmox VE peuvent se lire en parallèle des phases suivantes.
Phase 2 : Confiance
Section intitulée « Phase 2 : Confiance »Le guide du nœud admin donne le montage complet ; les deux formations servent de référence quand vous butez sur un concept précis, flows et providers côté authentik, moteurs de secrets et politiques côté OpenBao.
Phase 3 : Cluster
Section intitulée « Phase 3 : Cluster »Suivez ces guides dans l'ordre affiché. Talos monte le cluster, GitOps définit comment vous y déploierez, et Traefik rend les applications joignables avec du HTTPS. Inverser les deux derniers vous fait publier des services que le dépôt Git ne décrit pas encore.
Phase 4 : Supply chain
Section intitulée « Phase 4 : Supply chain »Packer traite les images de VM, les deux autres guides traitent les images de conteneur et leur vérification. Le guide « par où commencer » est le bon point d'entrée si le sujet est neuf pour vous : il pose le vocabulaire attestation, provenance et SBOM avant les outils.
Évolutions futures
Section intitulée « Évolutions futures »Cette roadmap couvre les bases d'un homelab DevSecOps. Les évolutions ci-dessous n'ont pas d'ordre imposé : elles se déclenchent par un besoin réel, pas par une envie de complétude. La colonne Complexité vous aide à estimer le coût d'entrée, mais le vrai critère est ailleurs : chacun de ces chantiers ajoute une brique à maintenir et à sauvegarder. Le DR complet est le seul qui se justifie même sans besoin immédiat, parce qu'il se teste rarement et se découvre toujours au pire moment.
| Domaine | Évolution | Complexité |
|---|---|---|
| Haute dispo | Cluster K3s multi-master, HAProxy | Moyenne |
| Storage | Longhorn, Rook-Ceph, NFS-CSI | Variable |
| Multi-tenant | Namespaces, NetworkPolicies, Quotas | Moyenne |
| Observabilité avancée | OpenTelemetry, Loki, Tempo | Moyenne |
| DR complet | Velero, site secondaire | Élevée |
À retenir
Section intitulée « À retenir »- Phase 1 (réseau) conditionne tout le reste : LAN propre, accès distant, DNS de base
- Phase 2 (confiance) évite la dépendance circulaire : authentik et OpenBao vivent hors cluster
- Phase 3 (cluster) est le terrain de jeu : Talos + ArgoCD pour démarrer
- Phase 4 (industrialisation) est continue : ajoutez les pratiques progressivement
- Documentez votre setup : vous vous remercierez dans 6 mois