3 articles tagués avec « argocd »

Une alerte de supervision s'est déclenchée : le watchdog de la plateforme était DOWN. En quelques minutes, le tableau devenait moche — le DNS du cluster refusait les connexions, et peu après, les volumes de stockage distribué ont cessé de se reconstruire. Une cascade de manuel.

Voici le post-mortem complet : comment la panne s'est propagée, pourquoi la cause évidente s'est révélée être un symptôme situé à trois niveaux de la racine, le correctif, et — surtout — la prévention livrée pour qu'elle ne puisse pas se reproduire de la même manière. Chaque changement évoqué ici est une pull request publique et vérifiable.

La plateforme en question — minicloud — est un environnement Kubernetes de qualité production tournant sur des ThinkPads reconditionnés, construite et opérée en solo comme simulation du système d'information d'une entreprise. Du bare-metal, aucun plan de contrôle managé, aucun filet de sécurité. C'est précisément pour cela qu'elle enseigne bien.

Chaque cluster Kubernetes qui utilise cert-manager pour le TLS porte en lui le même risque silencieux : la clé privée de la CA qui signe tous vos certificats internes se trouve dans un secret Kubernetes, stocké en clair dans le datastore de votre cluster.

Sur les clusters managés avec chiffrement etcd au repos, ce risque est correctement atténué. Sur k3s avec kine et SQLite — comme tournent beaucoup de clusters bare-metal — la table des secrets est en clair. Quiconque peut lire state.db depuis le nœud du plan de contrôle peut extraire la clé privée de votre CA et forger des certificats que tout votre cluster fait confiance.

Cet article couvre comment nous avons migré la clé privée de la root CA minicloud dans le moteur de secrets PKI de HashiCorp Vault, avec le même certificat de CA pour que rien d'autre n'ait à changer — aucune reconfiance, aucune interruption, aucun changement sur nos 43 ressources Certificate.

Chaque fois que je mettais à jour la config du dashboard Homer, je devais lancer kubectl rollout restart deployment/homer -n homer après qu'ArgoCD ait fini de synchroniser. Pareil pour LiteLLM quand le routage changeait. Pareil pour Backstage après toute mise à jour de catalogue ou de proxy. Le motif était identique à chaque fois : pousser vers git, attendre la synchronisation ArgoCD, puis déclencher manuellement un redémarrage de pod.

C'est une odeur opérationnelle. Si git est le seul chemin d'écriture, le redémarrage devrait être automatique aussi.