Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

voûte : génération des secrets Nextcloud de Technolibre

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-08-03 15:57:15 -04:00
parent 4dd3d46412
commit 6bef0e0343
1 changed files with 33 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
CHANGELOG.md
View file

@ -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