Nœud admin Proxmox : authentik et OpenBao

Le nœud admin héberge vos services de confiance : authentik (SSO/identité), OpenBao (secrets), et bientôt votre PKI interne. Ces services ne doivent pas dépendre du cluster applicatif qu'ils sécurisent, d'où un serveur séparé.

Ce guide ne décrit pas encore la plateforme finale. Il documente la mise en place du premier nœud de confiance du homelab, dans l'architecture actuelle, avant l'arrivée du cluster applicatif et de la segmentation réseau avancée.

Pourquoi un nœud admin séparé ?

Le problème de la dépendance circulaire

La dépendance circulaire apparaît dès qu'un service héberge ce dont il a besoin pour redémarrer. Le scénario ci-dessous n'a rien de théorique : c'est la panne classique du homelab qui consolide tout sur un seul cluster.

Votre cluster Kubernetes Talos héberge authentik
authentik gère l'accès à ArgoCD, Vault, et aux autres apps
Le cluster plante ou doit être recréé
→ Vous ne pouvez plus vous authentifier nulle part
→ Impossible de redéployer quoi que ce soit

Solution : les services de confiance vivent en dehors du cluster applicatif.

Architecture à 2 couches

La séparation se lit de haut en bas sur le schéma. La couche de confiance ne contient que des services dont dépendent tous les autres : identité, secrets, certificats. Elle tourne sur un hyperviseur unique, sans orchestrateur, précisément parce qu'un orchestrateur ajouterait une dépendance de plus. La couche d'exécution porte tout le reste et peut être détruite et reconstruite sans perdre l'accès au reste du homelab. La règle qui découle de ce découpage : rien de la couche haute ne doit avoir besoin de la couche basse pour démarrer.

Prérequis

Élément	Recommandation
Machine physique	Mini-PC avec 16-32 Go RAM, 256+ Go SSD, AMD Ryzen ou Intel N100+
Réseau	OPNsense opérationnel avec un LAN principal en `192.168.10.0/24` et un accès distant validé (voir guide précédent)
Stockage	Idéalement un SSD dédié pour les VMs (séparé de l'OS)

Étape 1 : Installer Proxmox VE

Proxmox VE est un hyperviseur basé sur Debian. Il vous permet de créer des VMs et des conteneurs LXC depuis une interface web.

Installation express

L'installateur Proxmox écrase intégralement le disque cible, il n'y a pas de partitionnement manuel à ce stade. Deux choix faits pendant l'installation seront pénibles à corriger ensuite : le nom d'hôte, qui se retrouve dans les certificats du cluster, et l'adresse IP, sur laquelle s'appuie toute la configuration ultérieure. Fixez-les maintenant en accord avec le plan d'adressage de votre OPNsense.

Téléchargez l'ISO sur proxmox.com/downloads

Créez une clé USB bootable

sudo dd if=proxmox-ve_*.iso of=/dev/sdX bs=4M status=progress

Installez Proxmox VE
- Bootez sur la clé USB
- Choisissez le disque cible (SSD principal)
- Configurez le hostname : proxmox-admin.lab.local
- IP sur le LAN actuel : 192.168.10.10/24
- Gateway : 192.168.10.1 (OPNsense)
Accédez à l'interface web
```
https://192.168.10.10:8006
```

Guide détaillé : Installation Proxmox VE

Post-installation essentielle

Sans licence, Proxmox pointe par défaut sur le dépôt entreprise auquel vous n'avez pas accès : chaque apt update renvoie une erreur 401 et aucune mise à jour ne passe. Basculer sur le dépôt pve-no-subscription est donc la première action après l'installation, pas une optimisation facultative. Les deux étapes suivantes préparent l'accès distant : résolution DNS interne et authentification SSH par clé.

Désactivez le repo entreprise (sauf si vous avez une licence)

Le format des fichiers de dépôt a changé entre les versions majeures. Proxmox VE 9 (base Debian 13 « trixie ») utilise le format deb822 dans des fichiers .sources :

# Dans le shell Proxmox, PVE 9 (trixie)
sed -i -e '/^Enabled:/d' -e '$a Enabled: no' /etc/apt/sources.list.d/pve-enterprise.sources
cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
apt update && apt dist-upgrade -y

Proxmox VE 8 (base Debian 12 « bookworm ») utilise encore l'ancien format sur une ligne :

# Dans le shell Proxmox, PVE 8 (bookworm)
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
apt update && apt dist-upgrade -y

Le panneau Repositories du résumé du nœud fait la même chose en deux clics et affiche l'état de chaque dépôt. Dans les deux cas, vérifiez avec apt update : plus aucune ligne enterprise.proxmox.com ne doit remonter en erreur.

Configurez la résolution DNS

Éditez /etc/resolv.conf pour pointer vers OPNsense :
```
nameserver 192.168.10.1
search lab.local
```

Ajoutez votre clé SSH

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAA..." >> ~/.ssh/authorized_keys

Guide détaillé : Configuration post-installation Proxmox

Étape 2 : Déployer authentik

authentik est une solution SSO/Identity Provider open source. Elle vous permettra de :

Créer un portail d'authentification unique pour toutes vos apps
Centraliser la gestion des utilisateurs et groupes
Activer le MFA (TOTP, WebAuthn, etc.)
Intégrer des apps via OIDC, SAML, LDAP, ou proxy

Options de déploiement

Deux formats possibles, et le choix n'est pas neutre pour un service d'identité. Le conteneur LXC partage le noyau de l'hôte : il démarre en quelques secondes et consomme peu, mais faire tourner Docker à l'intérieur impose d'activer l'option nesting, qui relâche une partie de l'isolation. La VM consomme davantage de mémoire et démarre plus lentement, en échange d'une frontière matérielle nette avec l'hyperviseur. Pour un service qui détient vos identités, la VM est le choix défendable ; le LXC reste acceptable sur un homelab où l'hyperviseur et le conteneur relèvent du même périmètre de confiance.

Conteneur LXC
VM dédiée

Pour un homelab, un conteneur Debian avec Docker est le plus simple :

Créez un conteneur LXC dans Proxmox :
- Template : debian-12-standard
- RAM : 4 Go minimum (8 Go recommandé)
- Disk : 20 Go
- IP : 192.168.10.20/24
- Activez "nesting" (requis pour Docker)

Installez Docker

# Docker depuis le dépôt officiel signé
apt-get update && apt-get install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
. /etc/os-release
curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" > /etc/apt/sources.list.d/docker.list
apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Déployez authentik avec Docker Compose

Suivez le guide officiel ou le nôtre (voir lien ci-dessous).

Guide détaillé : Installation authentik

Ce qu'authentik pourra protéger ensuite

Le tableau distingue deux familles d'intégration, et la différence conditionne l'effort. Une application qui parle OIDC nativement (Proxmox, ArgoCD, Grafana) se déclare en quelques champs et délègue proprement l'authentification. Une application sans notion de SSO passe par le proxy authentik en mode Forward Auth : authentik s'intercale devant elle et n'ouvre le passage qu'aux sessions valides. Cette seconde voie protège l'accès mais ne crée pas de compte dans l'application cible, ce qui limite ce qu'on peut en attendre en matière de traçabilité.

Application	Méthode d'intégration
Proxmox VE	OIDC (realm externe)
ArgoCD	OIDC
Grafana	OIDC
Traefik Dashboard	Proxy authentik (Forward Auth)
Applications web sans SSO	Proxy authentik
CLI / scripts	Service accounts + API tokens

Étape 3 : Déployer OpenBao (Vault)

OpenBao est le fork communautaire de HashiCorp Vault. Il stocke et gère vos secrets de manière sécurisée :

Secrets statiques : mots de passe de bases de données, tokens API, etc.
Secrets dynamiques : génération à la demande de credentials à durée limitée
PKI : émission de certificats X.509
Transit : chiffrement/déchiffrement via API (vos apps n'ont jamais la clé)

Pourquoi hors du cluster ?

Si OpenBao est dans votre cluster Talos, et que Talos a besoin de secrets au démarrage → problème de l'œuf et de la poule.

En le plaçant sur le nœud admin :

Talos démarre et récupère ses secrets depuis OpenBao
Les apps récupèrent leurs secrets via l'agent Vault
Si le cluster est recréé, OpenBao est toujours là

Déploiement

Pour ce homelab, je pars sur une première instance OpenBao hébergée sur le nœud admin Proxmox. Le format exact (LXC ou VM) pourra évoluer ensuite selon les besoins d'isolation et d'automatisation.

Créez un conteneur LXC (ou VM) :
- RAM : 2 Go
- Disk : 10 Go
- IP : 192.168.10.21/24

Installez OpenBao

Le projet publie un fichier checksums-linux.txt à côté des paquets. Contrôlez l'empreinte avant d'installer : un secret manager compromis à l'installation rend inutile tout le reste du dispositif.

BAO_VERSION=2.5.5
base="https://github.com/openbao/openbao/releases/download/v${BAO_VERSION}"
curl -sSfLO "${base}/openbao_${BAO_VERSION}_linux_amd64.deb"
curl -sSfLO "${base}/checksums-linux.txt"

grep " openbao_${BAO_VERSION}_linux_amd64.deb\$" checksums-linux.txt | sha256sum -c -
# -> openbao_2.5.5_linux_amd64.deb: OK

dpkg -i "openbao_${BAO_VERSION}_linux_amd64.deb"

Configurez (/etc/bao.d/bao.hcl) et initialisez
Stockez les clés de déverrouillage quelque part de sûr (pas sur ce serveur !)

Guide détaillé : Installation OpenBao

Répartition cible des services sur le nœud admin

À ce stade, votre nœud admin héberge :

Service	Positionnement initial	Usage
Proxmox VE	hôte physique (`192.168.10.10`)	Hyperviseur
authentik	VM ou LXC dédié (`192.168.10.20`)	SSO/OIDC
OpenBao	VM ou LXC dédié (`192.168.10.21`)	Secrets
PKI interne	étape suivante	Certificats TLS internes

Sauvegarde minimale

Ces services sont critiques. Une sauvegarde régulière est indispensable.

Stratégie recommandée

Lisez la dernière ligne à part : les clés unseal ne suivent pas la logique des trois autres. Une sauvegarde de VM contenant les données OpenBao reste inexploitable sans elles, elles doivent donc vivre ailleurs que sur le nœud sauvegardé, et hors ligne. Les trois premières lignes relèvent d'une sauvegarde classique, avec une nuance sur authentik : un vzdump de la VM capture aussi PostgreSQL, mais un export applicatif reste plus simple à réinjecter dans une instance neuve.

Élément	Méthode	Fréquence
VM / conteneurs Proxmox	Proxmox Backup Server ou vzdump	Quotidienne
Config authentik	Export via UI ou dump PostgreSQL	Hebdomadaire
Data OpenBao	Snapshot Raft ou backend storage	Quotidienne
Clés unseal OpenBao	Stockage offline hors site	Une fois (puis rotation)

Guide détaillé : Sauvegardes Proxmox

Vérifications

Tests authentik

authentik expose deux points de contrôle sans authentification, documentés pour la supervision. /-/health/live/ répond HTTP 200 dès que le serveur tourne ; /-/health/ready/ ne répond 200 que si la connexion à PostgreSQL est établie. C'est cette seconde URL qui vous intéresse ici : elle distingue un serveur démarré d'un serveur réellement opérationnel.

# Depuis votre poste
curl -k -o /dev/null -w '%{http_code}\n' https://auth.lab.local/-/health/ready/

La sortie attendue est 200. Le -k désactive la vérification du certificat, nécessaire tant que votre PKI interne n'émet pas encore les certificats du homelab ; retirez-le dès que la chaîne de confiance est en place. Pour connaître la version installée, l'endpoint /api/v3/admin/version/ existe mais exige un jeton d'API, il ne convient pas à un test de bon fonctionnement.

Tests OpenBao

La commande bao status interroge le serveur défini par la variable BAO_ADDR et n'a pas besoin de jeton : elle répond même quand le coffre est scellé. Deux champs comptent dans la sortie. Sealed indique si le coffre est déverrouillé : à true, aucune lecture de secret n'est possible et c'est l'état normal après un redémarrage. Initialized doit valoir true, sans quoi l'initialisation n'a jamais eu lieu. Le code retour de la commande encode ce statut : 0 si le coffre est déverrouillé, 2 s'il est scellé, 1 en cas d'erreur de connexion. Un script de supervision qui traite tout code non nul comme une panne confondra donc « scellé » et « injoignable ».

# Définir l'adresse
export BAO_ADDR='https://vault.lab.local:8200'

# Vérifier le statut
bao status

Checklist du premier palier

Cette liste est le critère de sortie du premier palier. Les deux points sur les clés unseal sont les seuls irrattrapables : tout le reste se refait en réinstallant, une clé perdue ne se retrouve pas. Traitez-les avant de passer au cluster applicatif.

Proxmox accessible via https://192.168.10.10:8006
authentik déployé et accessible
Compte admin authentik avec MFA activé
OpenBao initialisé et déverrouillé
Clés unseal stockées en lieu sûr (hors ce serveur)
Résolution DNS locale (si déjà mise en place)
Première sauvegarde effectuée

Prochaines étapes

Roadmap Homelab Les phases de déploiement de votre homelab complet

Formation authentik Maîtrisez authentik en profondeur : OIDC, proxy, LDAP

Formation OpenBao Secrets dynamiques, PKI, Transit, et plus

Déployer Talos Le cluster Kubernetes immutable pour vos workloads

À retenir

Nœud admin séparé : évite la dépendance circulaire avec le cluster applicatif
authentik : SSO/OIDC pour toutes vos applications
OpenBao : gestion centralisée des secrets
DNS interne : configurez *.lab.local pour simplifier les accès
MFA obligatoire : le compte admin authentik est la clé de voûte
Sauvegardez TOUT : particulièrement les clés unseal d'OpenBao