OPTAVIM est un de mes projets les plus ambitieux à ce jour. L'objectif : monter le système d'information d'une entreprise fictive multi-sites, du pare-feu jusqu'aux applications métier. C'était aussi une série de premières pour moi et mon groupe : mon premier vrai cluster Kubernetes monté à la main avec kubeadm, mes premiers pas sérieux sur Active Directory et sur pfSense. Une stack entière à apprendre, avec la sécurité comme fil conducteur du début à la fin.
Cet article fait le tour de l'architecture et montre les briques avec lesquelles j'ai travaillé.
Vue d'ensemble
OPTAVIM, c'est une entreprise répartie sur plusieurs sites, tous reliés à un datacenter central par des tunnels VPN chiffrés :
- un siège à Paris, avec ses 3 contrôleurs de domaine et une double fibre,
- une agence stratégique à Bordeaux, avec management et utilisateurs sur deux liens WAN,
- deux agences classiques (Rennes et Brest), uniquement des postes utilisateurs,
- des télétravailleurs en accès distant, protégés par la 2FA
Le datacenter concentre le pare-feu, l'Active Directory, le stockage et un cluster Kubernetes qui héberge les applications.
Les trois types de site, du plus complexe au plus simple :
Le réseau : pfSense et la segmentation
C'est par là que l'on a commencé. Le datacenter est segmenté en VLAN, un par fonction : management, Active Directory, stockage NFS, Kubernetes, et une zone edge pour les load balancers. Le pare-feu pfSense tourne en haute disponibilité avec CARP, un nœud master et un slave qui se synchronisent.
J'ai appris à raisonner en deny par défaut : rien ne passe entre deux VLAN tant que ce n'est pas explicitement autorisé par une règle. Côté accès distant, deux serveurs OpenVPN cohabitent sur le pare-feu, un pour les liaisons site à site et un pour le télétravail. Un bastion SSH sert de point d'entrée unique depuis l'extérieur.
Le cœur : un cluster Kubernetes monté avec kubeadm
C'est la pièce dont je suis le plus fier. Six nœuds : trois masters en haute disponibilité, trois workers. Pas de distribution clé en main, c'est du kubeadm assemblé à la main, ce qui m'a forcé à comprendre ce qui se passe réellement dans le cluster, les interactions entre les différents composants : le plan de contrôle, le réseau de pods avec Calico, l'émission de certificats avec cert-manager couplé à l'autorité de certification d'Active Directory, et le provisionnement dynamique des volumes persistants sur les serveurs NFS.
Les serveurs NFS eux-mêmes sont en haute disponibilité, avec réplication des données via DRBD et une VIP qui bascule en cas de panne. La base de données passe par MariaDB Operator dans le cluster, avec Redis pour le cache. L'idée de bout en bout, c'est que rien ne repose sur une seule machine.
[!NOTE] Le piège de la base de données Au départ, on avait monté MariaDB en Galera directement dans le cluster. Mauvaise pioche : des split-brain à répétition, faute de nous être assez renseignés sur le quorum et le comportement réseau entre réplicas. On a fini par migrer vers MariaDB Operator, qui gère la réplication et la bascule proprement.
L'identité et la sécurité
C'est la partie qui donne du sens au reste. Active Directory est la source unique des comptes : trois contrôleurs de domaine, le DNS interne, les GPO pour gérer les postes Windows, et l'autorité de certification.
Par-dessus, Keycloak fédère l'annuaire en LDAPS et joue le fournisseur d'identité unique pour les applications, en OIDC ou en SAML selon ce que chacune supporte. privacyIDEA ajoute le second facteur, avec des jetons à usage unique pour le VPN télétravail. Le résultat : un employé se connecte avec son compte du domaine et retrouve ses outils, sans multiplier les mots de passe, et l'accès est restreint au groupe métier auquel il appartient.
Pour la supervision et la sécurité, Prometheus et Grafana collectent les métriques, et Wazuh joue le rôle de SIEM avec ses agents déployés sur les machines de l'infrastructure. Toute l'exposition vers l'extérieur passe par HAProxy puis Traefik, avec des certificats TLS et huit noms de domaine internes en *.optavim.corp.
Les applications métier
Au bout de la chaîne, trois applications qui simulent l'usage réel d'une entreprise : Dolibarr pour l'ERP, Nextcloud pour le cloud de fichiers, et OrangeHRM pour les ressources humaines. Toutes branchées sur le SSO, toutes alimentées par les comptes et groupes de l'Active Directory. Le flux complet va du poste utilisateur au pare-feu, puis à HAProxy, à Traefik, et enfin à l'application, avec l'authentification gérée par Keycloak en chemin.
Ce que ce projet m'a apporté
OPTAVIM m'a fait travailler avec une stack que je ne connaissais pas en profondeur ou que de nom parfois. Mon premier cluster Kubernetes sérieux en kubeadm, mes premiers pas sur Active Directory et pfSense, la mise en place d'un SSO complet, d'une authentification à deux facteurs, d'un SIEM. Surtout, j'ai compris comment ces briques s'articulent entre elles.
Le réflexe que je garde, c'est de penser en sécurité dès le départ plutôt qu'en option ajoutée à la fin si on en a le temps. Segmentation réseau, deny par défaut, identité centralisée, second facteur, supervision : ce ne sont pas des cases à cocher, ce sont des couches qui se renforcent. Construire OPTAVIM de zéro, cela a été la meilleure façon de le comprendre concrètement.
Ce que je ferais autrement
Avec le recul, cinq chantiers pour une v2 :
- Sortir l'observabilité et la base de données du cluster applicatif. Aujourd'hui Prometheus/Grafana et la base vivent dans le même cluster que les apps. Les isoler éviterait qu'un incident applicatif emporte la supervision ou les données avec lui.
- Passer en GitOps. Le cluster est versionné sur Git, mais les déploiements restent manuels. Brancher ArgoCD pour réconcilier automatiquement l'état désiré serait le prochain vrai pas.
- Passer le stockage des volumes sur Longhorn ou Ceph. Les volumes persistants reposent aujourd'hui sur des serveurs NFS répliqués en DRBD. NFS dépanne pour du partage de fichiers, mais il fait un mauvais backend de volumes Kubernetes : tout transite par une seule paire de serveurs et sa VIP, le verrouillage de fichiers s'accorde mal avec les bases de données, qui attendent du stockage bloc, et un volume n'y est jamais répliqué pour lui-même. Longhorn (simple à opérer) ou Ceph (plus complet) fournissent du stockage bloc distribué, répliqué entre les nœuds et provisionné dynamiquement via CSI.
- Interconnecter les sites en IPsec plutôt qu'en OpenVPN. Pour les liaisons site à site, IPsec serait plus standard et plus performant que l'OpenVPN actuel. Ça n'a pas été possible ici pour des raisons logistiques propres au projet, mais ce serait le choix par défaut sur une infrastructure réelle.
- Migrer le VPN télétravail vers WireGuard. À la place d'OpenVPN, WireGuard apporterait de meilleures performances et une configuration plus simple, avec une base de code bien plus réduite (donc une surface d'attaque moindre).
Stack : Proxmox, pfSense (CARP HA), Active Directory et AD CS, Kubernetes monté avec kubeadm (Calico, cert-manager), Keycloak, privacyIDEA, OpenVPN, HAProxy, NFS avec DRBD, MariaDB operator, Redis, Dolibarr, Nextcloud, OrangeHRM, Prometheus, Grafana, Wazuh.