From 6404570bd7a57f01d5a2bd70bf479732a4ae13a8 Mon Sep 17 00:00:00 2001 From: Gabriel Radureau Date: Sun, 20 Sep 2026 19:36:12 +0200 Subject: [PATCH] =?UTF-8?q?fix(crowdsec)=20=E2=80=94=20nom=20de=20machine?= =?UTF-8?q?=20stable=20:=20594=20LAPI=20fant=C3=B4mes=20s'=C3=A9taient=20e?= =?UTF-8?q?ntass=C3=A9es=20en=20base?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `cscli machines list` renvoyait 617 lignes le 2026-09-20, dont 594 `crowdsec-lapi-*` remontant au 2025-12-05. Une seule LAPI tourne à la fois : 593 étaient mortes. Le mécanisme n'est pas celui qu'on croit. Ce ne sont PAS des redémarrages — un redémarrage garde le nom du pod. Mesuré : 571 hashes de ReplicaSet DISTINCTS pour 594 enregistrements, soit un pod template qui change presque à chaque fois. Ce qui le change, c'est le `rolloutRestartTargets` du VaultDynamicSecret (crowdsec/templates/vaultdynamicsecret.yaml) : à chaque rotation de l'identifiant Postgres, VSO force un rollout → nouveau pod template → nouveau hash de ReplicaSet → nouveau nom de pod. Soit 2,05 par jour sur 290 jours. Le chart amont code en dur `CUSTOM_HOSTNAME` sur `metadata.name`, et l'entrypoint enregistre la LAPI sous ce nom : si .login (fichier d'identifiants) == CUSTOM_HOSTNAME et machine existante → « Local agent already registered », rien à faire sinon → cscli machines delete ; cscli machines add Le `delete` ne porte que sur le nom COURANT. L'enregistrement du pod précédent n'est jamais supprimé — d'où l'entassement, sans borne. Ça compte parce que la LAPI stocke son état dans le PostgreSQL externe de pi2, à `max_connections=100`, celui-là même qui a refusé des connexions le 2026-09-20 (SQLSTATE 53300) et fait crasher la LAPI trois fois. Correctif : fixer `CUSTOM_HOSTNAME` à `crowdsec-lapi`. Le premier démarrage fait delete+add sur ce nom, tous les suivants tombent sur « already registered » et n'écrivent plus rien. Le fichier d'identifiants survit aux redémarrages (/etc/crowdsec est un lien vers le PVC crowdsec-config, vérifié sur le pod), donc la comparaison sur `.login` tient dans le temps. ⚠ L'entrée doit vivre dans `lapi.env` : le chart émet sa propre définition de CUSTOM_HOSTNAME AVANT d'injecter `.Values.lapi.env`, et Kubernetes retient la DERNIÈRE occurrence en cas de doublon. Vérifié deux fois : `helm template` place bien la nôtre en position 7 contre 5 pour celle du chart, et un pod de test avec les deux définitions a renvoyé `crowdsec-lapi`. `kubectl apply` avertit « hides previous definition » — c'est attendu. ⚠ Ne pas « corriger » en retirant le rolloutRestartTargets : les identifiants arrivent par secretKeyRef, qui ne se recharge pas à chaud. Sans rollout, la LAPI garderait des identifiants révoqués par Vault. Les 614 enregistrements orphelins ont été supprimés à la main en amont de ce correctif (`cscli machines delete`, par lots), en excluant explicitement les trois pods vivants. ⚠ `cscli machines prune` aurait été le mauvais outil : il filtre sur le heartbeat, or la LAPI n'en émet pas (DISABLE_AGENT=true) — elle aurait été supprimée avec les morts. Co-Authored-By: Claude Opus 5 --- crowdsec/values.yaml | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/crowdsec/values.yaml b/crowdsec/values.yaml index 4bc52f8..d2dd07e 100644 --- a/crowdsec/values.yaml +++ b/crowdsec/values.yaml @@ -28,6 +28,48 @@ crowdsec: &crowdsec_config env: - name: TZ value: Europe/Paris + # ⚠ NOM DE MACHINE STABLE — NE PAS REVENIR AU NOM DU POD. + # + # Le chart amont code en dur `CUSTOM_HOSTNAME` sur `metadata.name` + # (templates/lapi-deployment.yaml). L'entrypoint s'en sert pour + # enregistrer la LAPI en base : + # si .login du fichier d'identifiants == CUSTOM_HOSTNAME et que la + # machine existe déjà → « Local agent already registered », rien à faire ; + # sinon → cscli machines delete puis add. + # Le `delete` ne porte QUE sur le nom courant : l'enregistrement de + # l'ancien pod, lui, n'est jamais supprimé. + # + # Or le pod change de nom bien plus souvent qu'on ne le croit. Ce n'est pas + # une histoire de redémarrages — un redémarrage garde le nom. C'est le + # `rolloutRestartTargets` du VaultDynamicSecret (templates/ + # vaultdynamicsecret.yaml) : à chaque rotation de l'identifiant Postgres, + # VSO force un rollout, ce qui change le pod template, donc le hash du + # ReplicaSet, donc le nom du pod. + # + # Mesuré le 2026-09-20 : 594 enregistrements `crowdsec-lapi-*` en base + # depuis le 2025-12-05, pour 571 hashes de ReplicaSet distincts — soit + # 2,05 par jour, sur 290 jours, et une seule LAPI vivante à la fois. + # Ils s'entassent dans le PostgreSQL externe de pi2, celui-là même qui a + # refusé des connexions le 2026-09-20 (SQLSTATE 53300) et fait crasher la + # LAPI 3 fois. + # + # Avec un nom fixe, le premier démarrage fait delete+add sur CE nom, et + # tous les suivants tombent sur « already registered » — plus aucune + # écriture. Le fichier d'identifiants survit d'ailleurs aux redémarrages + # (/etc/crowdsec est un lien vers le PVC crowdsec-config), donc la + # comparaison sur `.login` tient dans le temps. + # + # ⚠ Cette entrée DOIT rester dans `lapi.env` : le chart émet sa propre + # définition de CUSTOM_HOSTNAME AVANT d'injecter `.Values.lapi.env`, et en + # cas de doublon Kubernetes retient la DERNIÈRE. C'est ce qui permet de + # surcharger un champ que le chart n'expose pas. `kubectl apply` avertit + # « hides previous definition », c'est attendu. + # + # Ne pas « corriger » en supprimant le rolloutRestartTargets : les + # identifiants arrivent par secretKeyRef, qui ne se recharge pas à chaud. + # Sans rollout, la LAPI garderait des identifiants révoqués par Vault. + - name: CUSTOM_HOSTNAME + value: crowdsec-lapi # To enroll the Security Engine to the console - name: ENROLL_KEY value: "cmieq72i3000802jr1wx8kply"