- Architecture
- Réseau
Cluster Kubernetes piloté en GitOps
Tout l'état du cluster décrit dans un dépôt ; une fusion de branche est un déploiement, et rien ne se modifie à la main.
Le problème
Des applications déployées à la main, dont personne ne sait plus reconstituer la configuration exacte ; des mots de passe dans des fichiers ; un compte différent pour chaque outil ; et des services exposés sur Internet sans vraie porte d’entrée.
Ce que j’ai fait
- Un cluster Kubernetes dont tout l’état vit dans un dépôt Git : Flux applique ce qui est fusionné, et remet d’aplomb ce qui aurait été modifié à la main.
- Une authentification unique (Keycloak adossé à un annuaire OpenLDAP) : un compte par personne, des groupes qui ouvrent ou ferment l’accès application par application.
- Des secrets rangés dans un coffre (OpenBao), injectés dans les applications au moment voulu, jamais écrits dans un dépôt.
- Une publication sécurisée : les services internes restent sur le réseau local ; ceux qui sortent passent par un tunnel filtré et une porte d’authentification, avec des en-têtes de sécurité posés partout.
Le résultat
Déployer, c’est fusionner une demande de fusion relue. Revenir en arrière, c’est annuler un commit. Et l’historique Git répond à la question « qui a changé quoi, quand, et pourquoi ».