From b51933566bcf13844b7d43fb3a5ddfe377514ee1 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Fri, 7 Aug 2026 21:16:51 -0400 Subject: [PATCH] rotation : vault_keycloak_admin, et la contrainte d'ordre MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ce compte est le moyen de se changer lui-meme : regenerer la voute d'abord l'aurait rendu inapplicable — plus rien n'aurait pu s'authentifier pour poser la nouvelle valeur. L'ordre est inverse : s'authentifier avec l'actuelle, poser la nouvelle, verifier, PUIS ecrire la voute. C'est une procedure, pas un redeploiement. Meme contrainte pour `vault_openldap_admin`, qui reste a faire. Consigne au runbook §6.7, avec le rappel qu'une verification n'est pas un message de succes. Verifie : admin (voute) OK, groupe sysadmin et role grafana-admin intacts, rejeu a changed=0. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 20 ++++++++++++++++++++ docs/autorisation.md | 25 +++++++++++++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 0883a4e..0bbdcb6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,26 @@ ## 2026-08-06 — le chemin nord-sud devient dérivable +### `vault_keycloak_admin` : le secret qui est la clé de son propre changement + +Rotation faite, chaîne d'identité intacte (groupe, membre, rôle), rejeu à `changed=0`. + +**L'ordre n'est pas indifférent, et c'est le point à retenir.** Ce compte est le moyen de se +changer lui-même : régénérer la voûte d'abord l'aurait rendu inapplicable — plus rien n'aurait +pu s'authentifier pour poser la nouvelle valeur. + +``` +1. s'authentifier avec la valeur ACTUELLE +2. poser la nouvelle dans Keycloak +3. vérifier qu'elle fonctionne +4. seulement alors, écrire la voûte +``` + +C'est une **procédure**, pas un redéploiement — et la même contrainte vaut pour +`vault_openldap_admin`, qui reste à faire. Consigné au runbook (§6.7), avec le rappel qu'une +vérification n'est pas un message de succès. + + ### La rotation des comptes de secours devient possible — elle ne l'était pas Le runbook §6.6 promettait de régénérer les comptes de secours ; **le code ne savait pas le diff --git a/docs/autorisation.md b/docs/autorisation.md index 01368cd..5061474 100644 --- a/docs/autorisation.md +++ b/docs/autorisation.md @@ -194,6 +194,31 @@ dépendent ni de Keycloak, ni de l'annuaire. C'est le sens de D-40. déploiement y a eu accès. Les régénérer transfère réellement le contrôle. 3. **Le mot de passe de la voûte** elle-même, si le dépôt change de mains. +### 6.7 Faire tourner un secret : l'ordre n'est pas indifférent + +**Les comptes de secours des services** (`vault_grafana_admin`, `vault_forgejo_admin`, +`vault_nextcloud_admin`) se régénèrent en voûte, puis un redéploiement les applique. Les rôles +savent désormais *changer* un mot de passe existant, pas seulement le créer. + +**Le compte d'administration de Keycloak est différent : il est le moyen de se changer +lui-même.** Régénérer la voûte d'abord le rendrait inapplicable — plus rien ne pourrait +s'authentifier pour poser la nouvelle valeur. L'ordre est donc inversé : + +``` +1. s'authentifier avec la valeur ACTUELLE +2. poser la nouvelle valeur dans Keycloak +3. vérifier que la nouvelle fonctionne +4. seulement alors, écrire la voûte +``` + +C'est une **procédure**, pas un redéploiement. La même contrainte vaut pour tout secret qui +est aussi la clé de son propre changement — `vault_openldap_admin` en est un. + +**Et une vérification n'est pas un message de succès.** `grafana-cli` annonçait +« Admin password changed successfully » en écrivant dans une base qui n'était pas celle du +serveur. Ce qui l'a démasqué est l'**état** — le champ `updated` du compte, inchangé. Après +toute rotation, s'authentifier réellement avec la nouvelle valeur. + ## 7. Ce que ce document ne couvre pas **La gestion courante des comptes.** Créer, suspendre, réaffecter : c'est le travail du