Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux services n'aboutissaient pas et tout etait correct cote serveur — clients
OIDC, URI de rappel, secret identique (meme empreinte), CA de confiance,
aucune restriction de domaine. Le premier saut rejoue au curl montrait des
parcours sains.
Et la, plus rien a examiner : eventsEnabled = False. Keycloak ne gardait
aucune trace, ni des connexions ni des echecs. Manque de diagnostic, mais
surtout d'exploitation : « un sysadmin l'exploite sans IA » suppose qu'il
puisse lire lui-meme ce qui s'est passe.
Journal (connexions + actions d'administration, retention 14 jours)
reconcilie par le role, pas active a la main dans une console.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Quatre defauts mesures dans l'integration Keycloak/LDAP, meme famille : une
valeur declaree d'un cote, consommee de l'autre, rien qui verifie la jonction.
1. Aucune regle ne s'appliquait sur le chemin d'un vrai utilisateur. Sonde :
« abcd » refuse par l'operation etendue LDAP, accepte par Keycloak (204),
puis actif pour l'authentification. Keycloak ecrivait userPassword en
direct (ppolicy aveugle) et le realm n'avait aucune passwordPolicy.
2. ldap_entry ne fait que CREER : la politique etait figee a sa creation. Le
depot disait pwdMustChange TRUE, le serveur FALSE — une reconstruction
from-zero aurait ressuscite la boucle du 2026-08-07. ldap_attrs state=exact
reconcilie la politique et l'overlay (DN lu, pas devine).
3. syncRegistrations absent : un compte cree dans Keycloak n'atteignait jamais
ou=people — acces web, aucune boite, invisible du modele de groupes.
4. Le prenom pointait sur cn (nom complet) : « Administrateur systeme systeme ».
Ajoute roles/resoudre_politique_mdp : LA declaration, traduite en pwdPolicy,
passwordPolicy et anti-force-brute. Les deux roles la consomment sans la
redeclarer.
usePasswordModifyExtendedOp ET validatePasswordPolicy : la seconde est
porteuse, Keycloak se liant en rootDN et slapd n'appliquant pas ses controles
de qualite au rootDN. La premiere seule aurait paru juste sans tenir.
Verification : abcd -> 400 « minimum length 12 » et absent de LDAP ; mot de
passe conforme -> 204 puis ldapwhoami accepte ; POST users -> 201 ET present
dans ou=people. Second passage des deux playbooks : changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui
que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre
choix que de manipuler le mot de passe d'autrui.
- serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et
resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote,
et refus explicite si le plan ne declare pas de MTA.
- passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur
une map, sort en succes et n'ecrit rien (smtpServer reste vide).
- amorcage_acces_courriel redevient a declarer : cette adresse designe une
personne, hors du systeme qu'on amorce ; une boite interne serait illisible
tant qu'on n'a pas l'acces qu'on cherche justement a recuperer.
- autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart
d'adresse laisse par l'ancien mode READ_ONLY de la federation.
Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email
declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second
deploiement changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ldappasswd` ne peut pas le changer : `cn=admin` n'est pas une entree de la base
mais le rootDN declare dans cn=config. Le mot de passe vit dans `olcRootPW` et se
modifie par un bind EXTERNAL. L'echec etait sans degat — l'ancien fonctionnait
toujours, verifie avant de continuer.
Keycloak stocke le mot de passe de LIAISON dans sa base et le masque : la
reconciliation d'hier couvrait l'URL, les DN et le mode, pas `bindCredential`.
Tourner le secret aurait coupe Keycloak de l'annuaire. Comme la valeur est
masquee, la reconciliation passe par une empreinte.
Verifie consommateur par consommateur : synchro LDAP de Keycloak (qui prouve la
liaison), carte LDAP de Postfix, Dovecot actif. Les trois rejouent a changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`realm-admin` (role du client `realm-management`) est attache au GROUPE sysadmin.
Administrer le realm ne passe plus par le compte local. Portee : CE realm, jamais
`master` — le compte de secours reste hors d'atteinte du groupe, et c'est le sens
meme d'un acces de secours (D-40).
Les roles de CLIENT sont un espace de noms distinct : la declaration gagne
`roles_client`. L'API attend l'UUID du client, pas son clientId — interroger par
le nom rendait une erreur, la verification echouait toujours et la tache se
declarait `changed` a chaque passage. Deux passages consecutifs a changed=0.
La boucle de changement de mot de passe : `pwdMustChange: TRUE` signifie « quand
un ADMINISTRATEUR pose un mot de passe, l'utilisateur doit le changer ». Keycloak
ecrit en tant qu'administrateur — chaque changement relaye etait vu comme une
reinitialisation. Incompatible par construction avec un IdP qui relaie.
La contrainte est deplacee la ou l'utilisateur la voit : pwdMustChange FALSE cote
annuaire, action `UPDATE_PASSWORD` posee par Keycloak. J'avais eprouve pwdReset
au niveau LDAP, ou il marche, sans parcourir le chemin complet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le changement de mot de passe imposé echouait sur « Federated storage is not
writable » : `editMode=READ_ONLY` etait code en dur. Keycloak lisait l'annuaire
sans pouvoir y ecrire — `pwdReset` devenait un cul-de-sac, LDAP exigeant un
changement que Keycloak ne pouvait pas faire.
Trois modes, un seul tient avec la doctrine. `UNSYNCED` ferait ecrire Keycloak
dans SA base : Dovecot et Postfix, qui se lient directement a LDAP (D-39),
valideraient encore l'ancien mot de passe. Ca aurait « marche » a l'ecran en
cassant le courriel en silence. `WRITABLE` ecrit A TRAVERS : l'annuaire reste la
source unique, Keycloak n'en est qu'un client.
Le mode devient une variable et il est RECONCILIE : un provider cree en
READ_ONLY le serait reste a vie.
Deux fautes de ma part au passage : extraction ancree sur `$` alors que la ligne
finit par un guillemet, et pas de `|| true` — sous `pipefail`, un grep vide tue
le script. Masque par `no_log`, pour la troisieme fois aujourd'hui.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux services n'etaient pas encore deployes : les cabler maintenant vaut
mieux que les corriger apres. `porte_par` passe de `aucun` a `claim-groupe`.
Forgejo recoit --group-claim-name + --admin-group, et sa tache passe de « creer
si absent » a add-oauth OU update-oauth : le meme defaut que la federation
Keycloak — cree une fois, jamais corrige — l'attendait sinon.
Nextcloud recoit --mapping-groups + --group-provisioning, plus une tache qui
verse les membres du groupe d'habilitation dans le groupe interne `admin` : etre
dans un groupe projete ne donne aucun pouvoir en soi.
Le maillon qui manquait aux deux : AUCUN mapper de protocole n'emettait le claim.
Les groupes existaient dans le realm et n'apparaissaient dans aucun jeton — un
cablage correct des deux cotes et rien au milieu. `oidc-group-membership-mapper`
pose sur les trois clients, `full.path=false` pour que le claim porte `sysadmin`
et non `/sysadmin`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La chaine est complete : LDAP cn=sysadmin -> groupe de realm -> role
grafana-admin -> Admin dans Grafana. Ajouter quelqu'un au groupe dans l'annuaire
lui ouvre Grafana sans deploiement et sans que personne ne soit nomme (D-66).
Rejoue : changed=0.
Defaut de fond trouve en chemin : la federation LDAP n'etait JAMAIS reconciliee.
`federation-ldap.yml` creait le provider s'il manquait puis ne le corrigeait
plus — il pointait encore `ldaps://id-ldap-01...`, le nom errone corrige le matin
meme dans `resoudre_annuaire`. La synchronisation echouait sur `UnknownHost`.
C'est le revers de D-67 au mauvais endroit : l'INFRASTRUCTURE se reconcilie,
seules les appartenances ne le sont pas. URL, usersDn et bindDn sont desormais
corriges a chaque passage.
Et j'avais masque l'echec avec `|| true` : le mapper existait, le realm restait
vide, rien ne disait pourquoi. Retire — l'erreur remonte avec son message.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
oauth2-proxy fonctionne devant Icinga Web 2 : 302 vers Keycloak, qui federe
LDAP. Quatre defauts leves, dont trois du meme motif — un nom construit par
convention d'un cote, declare de l'autre.
1. Le secret de cookie etait en base64 STANDARD. oauth2-proxy decode en
url-safe : le decodage echoue, il retombe sur la chaine brute et se plaint de
sa LONGUEUR, jamais de l'encodage. Garde ajoutee qui refuse + et /.
2. L'issuer etait fabrique (`keycloak.<domaine>`), un nom que rien ne publie.
Le plan expose `auth.<domaine>` — c'est ce nom que le DNS resout et que nginx
sert. Derive desormais du champ `expose`.
3. Keycloak s'annoncait sous ce meme nom invente : « issuer did not match ».
Meme correctif a la source.
4. Le pare-feu est-ouest bloquait l'edge : nginx ne declarait son 443 qu'avec
`pair: externe`, que le devis est-ouest saute (il releve de la frontiere).
Le flux existait d'un seul cote et la matrice etait satisfaite. nginx declare
maintenant aussi son 443 depuis la flotte.
obs-01 et mon-01 deployees. 7 cibles Prometheus up, scrutees en TLS a travers
cinq zones du VRF.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fin des dernières poches de 'codé en dur' liées à l'instance d'origine :
- realm SSO centralisé sur l'intrant identite_realm (defaut chezlepro,
retro-compatible) ; les 4 rôles (keycloak/forgejo/grafana/oauth2_proxy)
en dérivent. Expose dans la GUI (panneau Intrants).
- vars brandees renommees generiques : chezlepro_timezone -> fuseau_horaire,
chezlepro_organisation -> organisation (chrony, openldap, GUI, docs).
Aucune reference fonctionnelle aux anciens noms. Le moteur ne porte plus le
nom d'un tenant. Technolibre a son propre realm (technolibre).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Décision d'archi : FQDN pour toute référence inter-services (non ambigu en
fédération — data-sql-01 existe chez plusieurs tenants — + nom canonique TLS).
- resoudre_base : db_host renvoie le FQDN (hote.domaine_interne) → propagé à
keycloak/forgejo/icinga (ils en dérivent tous). Résolu par le plancher.
- client_journal : loki_url dérivé du groupe serveur_loki en FQDN (fin du
10.0.14.11 périmé).
- nettoyage des defaults db_host IP morts (10.0.13.11, écrasés par resoudre_base).
Aucune IP littérale ne subsiste dans les defaults des rôles. verify-full OK
(SAN FQDN). S'applique au prochain déploiement.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- client_pki : root_ca.crt en 0644 (un cert racine est PUBLIC ; requis pour
que les clients TLS non-root — keycloak, forgejo… — puissent vérifier).
- serveur_keycloak : db-url-properties sslmode=verify-full + sslrootcert.
Incident maîtrisé : 1er essai, keycloak (user keycloak) ne pouvait pas lire
root_ca 0600 → SSO down → restauré en <1 min → corrigé (0644) → verify-full OK.
Prouvé : realm 200, sslmode=verify-full, aucune erreur SSL/DB.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Machinerie additive/idempotente dans serveur_keycloak (rbac-oidc.yml) :
rôles de realm + mapper 'roles' sur les clients choisis + assignations
rôle→utilisateur. kcadm à chaud (zéro coupure SSO). Grafana :
role_attribute_path (grafana-admin→Admin, grafana-editor→Editor, sinon
Viewer). Prouvé sur id-sso-01 (idempotence) : testmail = grafana-editor.
Complète le dashboard logs (Viewer-friendly) : les deux volets de la
question « testmail peut-il voir les logs ? ».
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
serveur_keycloak_theme_cache (défaut true=prod). À false, ajoute
spi-theme-static-max-age=-1 + cache-themes/templates=false dans keycloak.conf
→ ressources servies en no-cache : les tweaks de thème sont visibles sans
lutter contre le cache 'immuable' du navigateur. Bac à sable = false.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Thème login alliance-boreale (parent=keycloak + overlay CSS) reprenant
l'identité du site : ciel nocturne aurore, carte glassmorphism, logo étoile
(favicon du site), bouton dégradé aurore, police système (souveraineté).
Déployé dans themes/, appliqué au realm via kcadm loginTheme (idempotent).
Prouvé : page de login charge alliance.css (200) + logo.svg (200),
loginTheme=alliance-boreale actif.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rôle utilitaire partagé resoudre_annuaire (comme resoudre_base) : dérive la
connexion OpenLDAP du domaine_interne + un hôte surchargeable, au lieu de
répéter ldaps://id-ldap-01... dans chaque rôle. Facts uri/port/base_dn/
users_dn/bind_dn/bind_password (secret no_log).
Migrés + prouvés (config neutre, changed=0) : keycloak (fédération, testmail
token 200), dovecot + postfix (flux courriel livré de bout en bout).
Piège : les defaults d'un rôle inclus ne persistent pas hors de son
exécution — publier via set_fact.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Liste déclarative serveur_keycloak_clients (clientId, redirect_uris,
web_origins, secret) → tasks/clients-oidc.yml enregistre chaque client
confidentiel via kcadm (create-si-absent, no_log). Décision côté Keycloak
(creds admin non répandus dans les rôles app) ; secret = même var de voûte
que l'app.
Prouvé : client grafana supprimé → rôle → recréé → testmail se connecte à
Grafana ; redéploiement idempotent (changed=0). Déploiement Grafana au SSO
désormais autonome.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Le rôle configure via kcadm (idempotent) un realm applicatif + un provider
de stockage LDAP READ_ONLY vers OpenLDAP (LDAPS, uid/entryUUID/inetOrgPerson).
LDAPS validé par le truststore système (truststore-paths → bundle CA, racine
step_ca via client_pki, désormais requis sur le nœud). Secrets par environment
+ no_log. tasks/federation-ldap.yml.
Éprouvé avant codification, puis prouvé par le rôle : testmail (user LDAP)
obtient un token via le realm chezlepro (HTTP 200) ; redéploiement idempotent
(changed=0). Modèle d'identité A (OpenLDAP source → Keycloak fédéré) complet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Les rôles à secrets déclaraient serveur_X_password: "" avec la variable
de voûte seulement en commentaire — aucun mapping réel. Remplir la voûte
ne branchait donc rien (secret vide → assertion échoue).
Les 12 secrets des 8 rôles pointent maintenant vers leur source :
serveur_X_password: "{{ vault_X | default('') }}"
Comportement inchangé si la voûte est vide ; branché dès qu'elle a le
secret. Prouvé : assertion step_ca passe avec vault_step_ca_password.
Chaque instance remplit ses vault_* ; aucun mapping par instance.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
