From 6bef0e034333531b3017efc3ea1c54b62d735a3f Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Mon, 3 Aug 2026 15:57:15 -0400 Subject: [PATCH] =?UTF-8?q?vo=C3=BBte=20:=20g=C3=A9n=C3=A9ration=20des=20s?= =?UTF-8?q?ecrets=20Nextcloud=20de=20Technolibre?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit vault_nextcloud_admin et vault_nextcloud_oidc étaient exigés par le plan et absents de la voûte réelle. Générés (32 octets urlsafe) en mémoire, avec relecture et aller-retour de chiffrement vérifiés avant écriture, jamais affichés. Idempotent : une clé renseignée n'est pas touchée ; une clé présente mais vide compte comme absente. Générer était légitime parce qu'Ansible configure les deux côtés depuis la même variable — le client Keycloak déclare secret: "{{ vault_nextcloud_oidc }}" et le rôle Nextcloud lit la même clé. Contre-exemple relevé chez Chezlepro : vault_opnsense_api_key/_secret manquent aussi, mais ne doivent PAS être générés — OPNsense est hors flotte et émet lui-même ses identifiants d'API. On génère un secret dont le dépôt est la source, jamais un secret dont un tiers est la source. Lacune connexe non corrigée : aucun tenant ne déclare de client OIDC Nextcloud dans serveur_keycloak.yml. Le secret existe, le client qui doit le porter non. 28 preuves OK, 0 échec, 0 sautée (voûte lisible). Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index cf374a7..33e3ae9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,38 @@ # CHANGELOG — Set-OPS +## 2026-08-03 (suite 14) — les deux secrets Nextcloud, et un qui ne se génère pas + +`vault_nextcloud_admin` et `vault_nextcloud_oidc` étaient exigés par le plan et absents +de la voûte réelle de Technolibre. Générés (32 octets `urlsafe`), en mémoire, avec +relecture et aller-retour de chiffrement vérifiés avant écriture ; jamais affichés. +L'opération est **idempotente** : une clé déjà renseignée n'est pas touchée, et une clé +présente mais vide compte comme absente — c'est le cas du gabarit recopié. + +Générer était légitime ici parce qu'**Ansible configure les deux côtés depuis la même +variable** : le client Keycloak déclare `secret: "{{ vault_nextcloud_oidc }}"` et le rôle +Nextcloud lit la même clé. La valeur n'a pas à préexister ailleurs. + +Harnais complet, voûte lisible : **28 preuves OK, 0 échec, 0 sautée**. + +### Le contre-exemple, trouvé chez Chezlepro + +La même vérification y signale `vault_opnsense_api_key` et `vault_opnsense_api_secret` +absents. **Il ne faut surtout pas les générer.** OPNsense est hors flotte : ses +identifiants d'API sont émis par le boîtier (System > Access > Users > API keys), et le +secret n'est affiché qu'à la création. Une valeur inventée serait syntaxiquement +correcte et refusée à la première requête. + +La distinction vaut d'être retenue : on génère un secret dont **le dépôt est la source**, +jamais un secret dont **un tiers est la source**. Le boîtier n'étant pas encore installé, +la question ne se pose pas avant sa mise en service. + +### Une lacune connexe, non corrigée + +Aucun des deux tenants ne déclare de **client OIDC Nextcloud** dans +`group_vars/serveur_keycloak.yml` — seulement grafana, forgejo et icingaweb2. Le secret +existe donc désormais des deux côtés, mais le client qui doit le porter n'est pas +déclaré. À ajouter avant tout déploiement de `collab-01`, sur le patron des trois autres. + ## 2026-08-03 (suite 13) — le cluster répond, et il contredit trois hypothèses Reconnaissance **en lecture seule** de l'API Proxmox, avec le jeton de la voûte. Trois