Skip to content

Architecture — Vue d'ensemble

Ce document décrit l'architecture physique et logique du homelab DevSecOps. Elle repose sur trois principes : isolation au niveau applicatif, sécurité par couches, et reproductibilité par le code.

Cluster Proxmox — 3 nœuds identiques

Le socle de l'infrastructure est un cluster Proxmox VE 9.2 composé de trois Nab6-Lite (Intel NUC-like). Chaque nœud est rigoureusement identique :

Composant Spécification
CPU Intel Core i5-12600H (12 cœurs / 16 threads)
RAM 16 Go (pve01), 32 Go (pve02, pve03)
Stockage système 500 Go NVMe (Proxmox OS)
Stockage VMs 1 To SSD (datastore local)
Réseau 1 × NIC 1 Gbps
Modèle Nab6-Lite

Pas de HA, pas de Ceph. Chaque VM vit sur le nœud où elle est créée. En cas de panne d'un nœud, ses VMs sont indisponibles jusqu'à la restauration. C'est un choix délibéré : sur 3 nœuds avec 1 GbE et pas de switch managé, un cluster Ceph ferait plus de mal que de bien.

Répartition des charges

Chaque nœud a un rôle défini :

pve01 — Control Plane & Réseau — 192.168.1.10 (16 Go)

Point d'entrée unique de l'infrastructure. Expose les services vers l'extérieur (Traefik), centralise le code (GitLab) et les secrets (Vault).

ID VM vCPU RAM Stockage IP
101 traefik 1 2 Go 20 Go 192.168.1.20
102 gitlab 4 8 Go 200 Go 192.168.1.21
103 vault 1 2 Go 20 Go 192.168.1.22
Total nœud 6 12 Go 240 Go

pve02 — Data, Sécurité & Observabilité — 192.168.1.11 (32 Go)

Héberge les services de registre, monitoring, SSO et gestion de vulnérabilités. Aucun service exposé directement sur Internet.

ID VM vCPU RAM Stockage IP
201 harbor 2 4 Go 80 Go 192.168.1.30
202 monitoring 2 4 Go 100 Go 192.168.1.31
203 keycloak 2 4 Go 40 Go 192.168.1.32
204 defectdojo 2 4 Go 50 Go 192.168.1.33
Total nœud 8 16 Go 270 Go

pve03 — Kubernetes Platform — 192.168.1.12 (32 Go)

Cluster Kubernetes k3s orchestré en GitOps via ArgoCD. Les applications Python (FastAPI, Streamlit, Flask) sont déployées ici.

ID VM vCPU RAM Stockage IP
301 k3s-master 2 4 Go 40 Go 192.168.1.40
302 k3s-worker01 3 6 Go 100 Go 192.168.1.41
303 k3s-worker02 3 6 Go 100 Go 192.168.1.42
Total nœud 8 16 Go 240 Go

Contrainte réseau : pas de switch managé

Le réseau domestique est en 192.168.1.0/24 avec la passerelle Freebox en 192.168.1.254. Aucun switch manageable — donc pas de VLANs 802.1Q physiques.

Comment isoler malgré tout ?

Dans cette topologie, toutes les VMs sont sur le même segment L2. L'isolation repose sur :

Couche Mécanisme Rôle
Firewall applicatif UFW sur chaque VM Blocage des ports non nécessaires, restriction des sources autorisées
Anti-bruteforce Fail2Ban sur chaque VM Bannissement temporaire après X échecs SSH ou HTTP
Firewall Proxmox nftables sur l'hyperviseur Protection du nœud Proxmox lui-même (management, API)

Pourquoi pas nftables sur le Proxmox pour le filtrage inter-VM ? En flat network, les paquets entre VMs d'un même bridge ne traversent pas la chaîne forward de l'hyperviseur — le switch virtuel les délivre directement. Le seul endroit où filter est efficace, c'est sur la VM elle-même (INPUT chain via UFW).

Point d'entrée unique

Tout le trafic externe passe par traefik (192.168.1.20), ports 80 et 443 uniquement.

Internet (Freebox)
    │
    ├── 80/443 → traefik.mounik.ovh
    │               ├── gitlab.mounik.ovh     → 192.168.1.21
    │               ├── vault.mounik.ovh      → 192.168.1.22
    │               ├── harbor.mounik.ovh     → 192.168.1.30
    │               ├── grafana.mounik.ovh    → 192.168.1.31
    │               ├── keycloak.mounik.ovh   → 192.168.1.32
    │               ├── defectdojo.mounik.ovh → 192.168.1.33
    │               ├── argocd.mounik.ovh     → 192.168.1.40 (via k3s Ingress)
    │               └── app-*.mounik.ovh      → 192.168.1.41/42 (via k3s Ingress)
    │
    └── challenge DNS Let's Encrypt (API OVH)

Certificats TLS : wildcard *.mounik.ovh via Let's Encrypt en challenge DNS OVH.

CrowdSec : déployé sur la VM traefik en mode bouncer pour bannir automatiquement les IPs malveillantes.

Authentification centralisée

Keycloak (keycloak.mounik.ovh) est le fournisseur SSO OIDC unique. Tous les services exposés (GitLab, Grafana, Harbor, DefectDojo, ArgoCD) délèguent leur authentification à Keycloak. Un seul compte, un seul mot de passe, une seule session.

Gestion des secrets

Tous les credentials (clés API, tokens, mots de passe) sont dans Vault (vault.mounik.ovh) — jamais en clair dans le code ni dans les variables CI/CD. Les pipelines GitLab.com utilisent vault agent pour injecter les secrets au moment du déploiement.

Choix techniques

Choix Alternative Justification
Proxmox VE VMware vSphere, Hyper-V Open-source, API REST native, intégration OpenTofu, gratuit
OpenTofu Terraform Fork open-source de Terraform après la licence BSL (2023). Syntaxe HCL identique. Supporté par la Linux Foundation. En entreprise les deux coexistent — maîtriser l'un c'est maîtriser l'autre.
Ansible Puppet, SaltStack Agentless, SSH uniquement, idéal pour un homelab sans infrastructure de gestion
GitLab.com Self-hosted GitLab Pas de负担运维. Le code IaC vit sur GitLab.com, la CI/CD déploie sur le homelab.
k3s k3s standard, MicroK8s Certifié Kubernetes, léger (binaire unique), SQLite au lieu d'etcd → économique en RAM
Traefik v3 Nginx, HAProxy Découverte auto des services, support Let's Encrypt natif, middleware CrowdSec
Vault SOPS + Age, Bitwarden PKI interne, rotation automatique, audit trail complet
Keycloak Authelia, Authentik, Dex SSO OIDC mature, gestion fine des rôles, federation, standard industriel
ArgoCD Flux CD, Jenkins X GitOps pur, interface web, sync automatique, multi-cluster
CrowdSec Fail2ban Blocklist communautaire partagée, bouncer Traefik natif, métriques Prometheus
UFW + Fail2Ban nftables pur Simplicité de gestion par VM, adapté au flat network. Fail2Ban pour la couche anti-bruteforce

Pour aller plus loin