Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
129 lines
7.2 KiB
Markdown
129 lines
7.2 KiB
Markdown
# Authentification : Keycloak devant, LDAP dessous, `sudo` en secours
|
|
|
|
> **Pour qui :** le **mainteneur** — la doctrine d'authentification, avant de brancher un service.
|
|
|
|
> **Directive d'architecture du 2026-08-03.** Trois règles, décidées ensemble et
|
|
> volontairement indissociables — chacune crée le problème que la suivante résout.
|
|
|
|
1. **Toute authentification web passe par Keycloak.** Aucun service ne tient son propre
|
|
répertoire de comptes.
|
|
2. **LDAP est la source de vérité unique** des comptes d'un tenant. Keycloak le fédère ;
|
|
les protocoles qui ne parlent pas OIDC s'y lient directement.
|
|
3. **Chaque service garde un accès de secours**, atteint par `sudo` sur l'hôte.
|
|
|
|
## 1. Pourquoi les trois vont ensemble
|
|
|
|
La chaîne est en série : `service → Keycloak → LDAP`. C'est ce qui donne « une identité, un
|
|
mot de passe » — et c'est aussi trois points de panne alignés. Si LDAP tombe, plus personne
|
|
n'entre nulle part, y compris pour réparer.
|
|
|
|
La règle 3 n'est donc pas une entorse au SSO : c'est ce qui rend les deux premières
|
|
tenables. Sans elle, la panne d'un maillon devient une exclusion totale.
|
|
|
|
## 2. Portée : le web, et seulement le web
|
|
|
|
| Protocole | Chemin d'authentification | Pourquoi |
|
|
|---|---|---|
|
|
| **HTTP(S)** — interfaces humaines | **Keycloak** (OIDC natif, ou `oauth2-proxy` devant) | c'est là que la directive s'applique |
|
|
| **IMAP / SMTP** | **LDAP direct** (Dovecot, Postfix) | ces protocoles ne parlent pas OIDC ; le flux est prouvé de bout en bout |
|
|
| **SSH** | **clé publique** (`PasswordAuthentication no`) | pas de mot de passe du tout, donc rien à fédérer |
|
|
| **PostgreSQL, Redis** | secrets applicatifs en voûte | comptes de service, pas d'humains |
|
|
|
|
Ce qui est interdit partout, c'est qu'un service tienne **son propre répertoire d'humains**.
|
|
Le chemin varie ; la source ne varie pas.
|
|
|
|
## 3. La posture retenue : la porte de secours n'est pas annoncée
|
|
|
|
Le compte local de chaque service **existe** — il ne peut pas dépendre de Keycloak, sinon il
|
|
tomberait avec lui. Mais son formulaire de connexion **n'est pas proposé au repos**.
|
|
|
|
Ce n'est pas une préférence esthétique. Un formulaire local ouvert en permanence :
|
|
|
|
- contourne la politique de mot de passe et le MFA ;
|
|
- contourne surtout la **révocation centrale** — désactiver quelqu'un dans LDAP laisserait
|
|
son compte local valide, sans que rien ne le signale ;
|
|
- offre une cible de bourrage d'identifiants sur `admin`, en continu, pour un usage qui
|
|
devrait être exceptionnel.
|
|
|
|
Le coût de la fermeture est nul depuis qu'on a tranché que **`sudo` suffit** : `sudo` *est*
|
|
le mécanisme de réouverture.
|
|
|
|
### Ce que chaque service sait vraiment faire
|
|
|
|
Vérifié auprès de l'amont le 2026-08-03, puis par **rendu réel des gabarits** dans les deux
|
|
postures — pas seulement lu.
|
|
|
|
| Service | Réglage | Effet réel | Secours par `sudo` |
|
|
|---|---|---|---|
|
|
| **Grafana** | `GF_AUTH_DISABLE_LOGIN_FORM=true` | ferme le formulaire | `grafana-cli admin reset-admin-password` |
|
|
| **Forgejo** ≥ 10 | `ENABLE_INTERNAL_SIGNIN=false` + `ENABLE_BASIC_AUTHENTICATION=false` | ferme la connexion interne **et** l'API en Basic | `forgejo admin user change-password` |
|
|
| **Nextcloud** | `hide_login_form=true` | **masque seulement** | `occ user:resetpassword`, ou `…/login?direct=1` |
|
|
|
|
> **Nextcloud est une exception, et il faut la dire.** `hide_login_form` **masque** le
|
|
> formulaire ; `…/login?direct=1` y accède encore, et l'amont le documente comme voulu —
|
|
> c'est ainsi qu'un administrateur entre. La protection est donc de **ne plus l'annoncer**,
|
|
> pas de l'interdire. Le présenter comme équivalent à Grafana ou Forgejo donnerait un faux
|
|
> confort.
|
|
|
|
Le réglage s'appelle `<rôle>_connexion_locale` dans les trois rôles, et vaut `false` par
|
|
défaut. Le passer à `true` rouvre la porte, explicitement.
|
|
|
|
**Garde de version.** `ENABLE_INTERNAL_SIGNIN` n'existe **que depuis Forgejo v10** (suivi
|
|
amont, ticket 7476 : *« This option was added to Forgejo v10 »*). Sur une version
|
|
antérieure il serait ignoré **sans erreur** — le rôle croirait avoir fermé la porte. Un
|
|
`assert` refuse donc `connexion_locale: false` sous 10.0.0 plutôt que de laisser croire.
|
|
|
|
## 4. La chaîne de secours
|
|
|
|
Trois maillons, aucun ne dépendant d'une porte web ouverte :
|
|
|
|
```
|
|
1. SSO Keycloak → LDAP ← la voie normale
|
|
2. sudo via SSH occ / grafana-cli / forgejo admin ← Keycloak ou LDAP en panne
|
|
3. console Proxmox de la VM ← SSH inaccessible
|
|
```
|
|
|
|
Un accès de secours qu'on ne sait pas emprunter n'existe pas : les commandes exactes sont
|
|
dans le tableau ci-dessus, et les mots de passe locaux vivent dans la voûte unique de
|
|
l'instance.
|
|
|
|
## 5. La garde : chaque rôle déclare sa position
|
|
|
|
Une directive qu'aucune garde ne vérifie finit par ne plus être vraie. Chaque rôle
|
|
`serveur_*` porte donc un `meta/authentification.yml`, et **P29** le confronte à son code.
|
|
|
|
| Portée | Sens | Rôles |
|
|
|---|---|---|
|
|
| `web-sso` | authentification humaine web → Keycloak (`mecanisme: natif` ou `oauth2-proxy`) | 5 |
|
|
| `socle-identite` | **est** la chaîne d'identité, ne peut pas se déléguer à elle-même | keycloak, openldap |
|
|
| `ldap-direct` | protocole non-OIDC lié à LDAP | dovecot, postfix |
|
|
| `interne-sans-auth` | interface joignable **dans** le tenant sans authentification, non exposée | prometheus, loki |
|
|
| `sans-auth-humaine` | aucun point d'authentification humaine | 12 |
|
|
|
|
La preuve refuse **l'oubli et le mensonge** : un rôle sans déclaration, une portée
|
|
inventée, un `web-sso` sans accès de secours ou sans posture de formulaire, un `web-sso
|
|
natif` sans réglage `<rôle>_connexion_locale` **défini dans `defaults`**, et une
|
|
déclaration que le code contredit.
|
|
|
|
> **Les indices doivent être nommés.** Une première version cherchait les mots « ldap » et
|
|
> « oidc » dans le rôle. Le mot *LDAP*, présent dans un commentaire de `serveur_grafana`,
|
|
> suffisait alors à valider une déclaration `ldap-direct` mensongère. La preuve exige
|
|
> désormais une **variable du namespace du rôle** (`<rôle>_oidc`, `<rôle>_ldap`) ou une URI
|
|
> `ldap://` — ce qu'une phrase en prose ne produit pas.
|
|
|
|
Une valeur mérite d'être expliquée : `formulaire_local: aucun`. Elle distingue un service
|
|
qui **n'a pas de compte local du tout** — `oauth2-proxy` est une passerelle — de celui qui
|
|
en a un et l'a fermé. Sans elle, on écrirait « fermé », ce qui laisserait croire qu'une
|
|
porte a été close alors qu'il n'y en a jamais eu.
|
|
|
|
### Les lacunes sont comptées, pas masquées
|
|
|
|
`interne-sans-auth` ne fait pas échouer la preuve : c'est une lacune **assumée et nommée**.
|
|
Mais elle est comptée à chaque exécution, donc visible dans chaque rapport. La refuser
|
|
bloquerait le harnais sur une décision déjà prise ; la taire la ferait oublier.
|
|
|
|
Prometheus et Loki sont dans ce cas. À noter, contre une idée reçue de la veille : **ils ne
|
|
sont pas exposés publiquement** — aucun `expose` au plan. Seuls six groupes le sont
|
|
(collabora, forgejo, grafana, keycloak, nextcloud, oauth2-proxy). Le risque est donc
|
|
intra-tenant, pas frontalier — plus petit qu'annoncé, réel quand même. `oauth2-proxy` est
|
|
déjà éprouvé devant Icinga Web 2 : le patron existe, il reste à l'appliquer.
|