La commande que j'avais donnee etait circulaire : `gpg --recv-keys <empreinte>`
demande la cle PAR son empreinte, et une empreinte est le condensat du materiel
de la cle. Le serveur ne peut rien renvoyer d'autre. Ca n'etablit rien.
Elle a tout de meme revele l'identite : Keycloak Bot <keycloak.bot@gmail.com>,
ed25519 2024-02-13, expire 2027-02-12. Mesure localement : cle AUTO-SIGNEE
uniquement, aucune certification tierce.
L'ancre reelle : keycloak.org/keys publie
861ab50e8cc6611fb6bc01a6b8f12ea26fd6eeba, identique a l'epinglage. Canal
DISTINCT de github.com qui livre l'archive — la propriete qu'avait Forgejo et
qui manquait ici.
Deux reserves consignees dans le role plutot que tues : la page decrit la cle
comme servant aux artefacts Maven, et l'ancrage vaut ce que vaut le controle de
keycloak.org (DNS + TLS).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
« J'ai besoin d'une confiance reelle. Keycloak est probablement l'element le
plus dangereux de cet ecosysteme. » C'est exact : il signe les jetons de TOUT
l'ecosysteme, une archive substituee la et l'identite entiere tombe.
CORRECTION D'ABORD. J'avais ecrit que Keycloak ne publie aucune somme de
controle. Faux, et l'exploitant l'a releve. Mesure : .sha1 et .md5 existaient
jusqu'a 26.6.2 puis ont disparu a partir de 26.7.0 ; le .asc, lui, est present
sur toutes les versions — et je l'avais rate, sans meme le chercher. Une somme
prouve qu'un fichier n'est pas corrompu ; une signature prouve QUI l'a produit.
ETABLI : la meme cle 861AB50E...6FD6EEBA a signe 26.0.7 (alors en production),
26.3.0, 26.6.2 et 26.7.1. NON ETABLI : aucune source independante ne publie
cette empreinte — ni keycloak.org, ni SECURITY.md, ni un fichier KEYS ; absente
de keys.openpgp.org, trouvee sur keyserver.ubuntu.com qui n'est pas une
autorite. On prouve la continuite, pas l'origine. L'ancre reste une decision
humaine — desormais ecrite, versionnee, et verifiee a chaque telechargement.
scripts/verifier_signature.py impose trois choses, chacune contre un
contournement precis : la cle publique vit DANS LE DEPOT (aucun serveur de
cles au deploiement) ; l'empreinte est EPINGLEE, donc une rotation amont
devient un echec bruyant ; trousseau JETABLE, donc le resultat ne depend pas
du trousseau personnel. Il lit VALIDSIG et compare l'empreinte du signataire
REEL — « bonne signature » seule laisserait passer une signature valide faite
par une autre cle du trousseau.
Eprouve sur cinq cas : nominal 0 ; artefact altere d'un octet 1 ; empreinte
differente 1 ; cle du depot corrompue 1 ; signature absente 1.
Ce que ca ne prouve PAS : que l'empreinte epinglee soit la bonne. Aucune
machine ne peut l'etablir ; le script garantit qu'on ne s'en ecarte plus sans
le voir.
Verifie : role applique de bout en bout sur idm-01, ansible-lint production,
prouver.py 35 OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Comme pour Nextcloud, ce n'est PAS une migration : `id-sso-01` reste a 26.0.7
jusqu'a sa prochaine reconstruction. L'epinglage decrit ce qu'on INSTALLE.
VERIFICATION PLUS FAIBLE QUE POUR NEXTCLOUD, ET IL FAUT LE DIRE. Keycloak ne
publie AUCUNE somme de controle a cote de son archive sur GitHub — ni .sha1
ni .sha256, verifie. On ne peut donc pas comparer a une reference de
l'editeur. Ce qui a ete controle a la place :
- flux gzip valide de bout en bout (`gzip -t`, pas seulement l'en-tete) ;
- l'archive contient bien bin/kc.sh, lib/quarkus-run.jar et version.txt ;
- version.txt declare « Keycloak - Version 26.7.1 » — le contenu dit la
meme chose que le nom du fichier.
C'est un controle d'integrite et de coherence, pas d'authenticite. La
difference merite d'etre nommee plutot que noyee dans un « verifie ».
`make versions-mesurer` : il ne reste que Forgejo, 10.0.0 contre v16.0.2 —
six majeures, qui demandent de lire les notes de version avant, meme pour une
construction de zero.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
