Dernière mise à jour : juin 2026

Infrastructure à trois machines sur un LAN1 filaire, avec un réseau wifi (LAN2) isolé. Tous les services tournent sous Docker sur le serveur principal.

Internet
    |  443/80
    v
[ Routeur ]  ──(isolé)──>  [ LAN2 wifi ]
    |
    v  LAN1
[ Proxy — Caddy ]   TLS · Let's Encrypt · reverse proxy · forward_auth
    |
    v  LAN1 (ports internes)
[ Serveur principal ]
    |── Auth       : Kanidm · Authelia
    |── Services   : Nextcloud · Blog · DokuWiki · Ampache · MariaDB
    |── Surveillance : Cockpit · Uptime Kuma · Dozzle · CrowdSec · Homepage
    └── Stockage   : Soft-RAID mdadm 2 To (volumes Docker bindés)

[ Portables ×4 ]
    |── kanidm-unixd  (cache offline · PAM)
    |── Home local    (pas de NFS)
    |── Client Nextcloud · Client Ampache · Navigateur web (SSO)

• NAT entrant : ports 80 et 443 redirigés vers Caddy
• Pare-feu : LAN2 wifi isolé du LAN1 filaire
• Le serveur principal n'est jamais exposé directement à Internet

• Terminaison TLS et gestion des certificats Let's Encrypt
• Reverse proxy vers les services du serveur principal
• forward_auth vers Authelia pour chaque requête entrante
• Machines : proxy dédié sur LAN1, indépendant du serveur

• OS : Debian Trixie (13), kernel 6.x
• Matériel : AMD x86, 8 Go RAM, 2 To en soft-RAID (mdadm)
• Conteneurisation : Docker CE (dépôt officiel), Docker Compose v2
• Cockpit installé en bare-metal (hors Docker), accessible LAN uniquement sur :9090

Flux d'authentification :

• Login système portable : kanidm-unixd → Kanidm (cache local si offline)
• Services web (navigateur) : Caddy → forward_auth Authelia → Kanidm
• Client Nextcloud desktop/mobile : Nextcloud → LDAP → Kanidm directement
• Changement de mot de passe : interface web Kanidm → propagation au prochain sync

Gestion des droits :

• Groupes définis dans Kanidm (ex. music_users, wiki_editors, admin)
• Règles d'accès par groupe dans le fichier de config Authelia (YAML statique)
• Modification des droits → édition YAML + redémarrage Authelia

Nextcloud — deux chemins d'auth :

1. Navigateur web : Authelia intercepte, puis Nextcloud vérifie aussi via LDAP/Kanidm
2. Clients desktop/mobile : Nextcloud → LDAP → Kanidm directement (pas via Authelia)

Chaque portable dispose de :

• kanidm-unixd : daemon de cache credentials, authentification PAM
• Home local sur le disque du portable (pas de NFS)
• Au moins un login réseau réussi requis pour initialiser le cache offline

Mode offline : après le premier login, kanidm-unixd maintient un cache chiffré local. L'authentification fonctionne sans réseau. En cas de changement de mot de passe hors réseau, la resynchronisation se fait au prochain contact avec le serveur.

Exposition Kanidm vers l'extérieur : pour provisionner un nouveau portable hors LAN, Kanidm doit être accessible depuis Internet via Caddy sur un sous-domaine dédié, avec MFA activé (TOTP ou passkey).

• Soft-RAID mdadm sur le serveur principal, 2 To
• Toutes les données persistantes (fichiers Nextcloud, base MariaDB, musique Ampache) sont montées via bind mounts ou volumes nommés vers le RAID
• Les données ne vivent jamais dans les couches des conteneurs Docker
• Fichiers réseau (Samba/NFS) : hors Docker, accessibles uniquement sur le LAN1

Principe : chaque étape est fonctionnelle et stable avant de passer à la suivante. Retour arrière possible à tout moment.

Objectif : avoir de la visibilité sur le serveur avant de toucher aux services.

1. Installer Cockpit en bare-metal (apt install cockpit)
2. Déployer Dozzle (logs Docker)
3. Déployer Uptime Kuma (surveillance services)
4. Déployer Homepage (page d'accueil)
5. Vérifier l'état du RAID via Cockpit

Risque : quasi nul — outils de lecture uniquement, aucun impact sur l'existant.

Objectif : migrer les services actuels (bare-metal) vers Docker, un par un.

Ordre recommandé (du moins critique au plus critique) :

1. DokuWiki (pas de base de données, migration simple)
2. Blog (selon stack : WordPress ou statique)
3. MariaDB (conteneurisation de la base, snapshot avant migration)
4. Nextcloud (le plus complexe : permissions, config, clients existants)
5. Ampache (dépend du volume de fichiers musique à monter)

Règle : conserver l'ancien service bare-metal actif jusqu'à validation complète du conteneur.

Risque : moyen — planifier une fenêtre de maintenance par service.

Objectif : déployer Kanidm et connecter les portables, sans toucher aux services web.

1. Déployer Kanidm en conteneur
2. Créer les 4 comptes et les groupes
3. Installer kanidm-unixd sur chaque portable
4. Tester le login système + cache offline (couper le réseau et vérifier)
5. Connecter Nextcloud en LDAP vers Kanidm

Risque : moyen — tester le fallback offline avant de valider. Garder les comptes locaux sur les portables en parallèle pendant la période de test.

Objectif : protéger tous les services web derrière un portail de login unique.

1. Déployer Authelia
2. Configurer forward_auth sur Caddy (côté proxy)
3. Définir les règles d'accès par groupe dans le YAML Authelia
4. Tester service par service (DokuWiki en premier, Nextcloud en dernier)

Risque : moyen à élevé — une mauvaise config Authelia peut bloquer l'accès à tous les services. Prévoir un accès de secours direct (bypass temporaire sur une IP LAN fixe).

Objectif : renforcer la détection d'intrusions sans surcharger le serveur.

1. Déployer CrowdSec (analyse logs Caddy, SSH, Nextcloud)
2. Installer AIDE (intégrité fichiers système)
3. Configurer les alertes (mail ou webhook)

Risque : faible — outils passifs ou bloquants uniquement sur les IPs malveillantes connues.

Marge disponible sur 8 Go : confortable. Surveiller MariaDB et Nextcloud en charge réelle.

• MariaDB n'est jamais exposé hors du réseau Docker interne
• Cockpit accessible uniquement depuis le LAN (port 9090 bloqué au routeur)
• Kanidm exposé vers Internet uniquement pour le provisionnement des portables, avec MFA obligatoire
• Les fichiers réseau (Samba/NFS) restent hors Docker, LAN1 uniquement
• LAN2 wifi isolé : aucun accès direct au serveur principal