Daniel Allaire 4a1d0836d0 docs : un README par rôle (12 manquants) + carte remise à l'état du code

Solde la dette documentaire repérée à l'audit du 2026-07-03. Tous les rôles ont
désormais un README, au format maison (intention → rôle → variables →
notes/limites → prérequis). Ils documentent ce qui ne se lit PAS dans les tâches :

- serveur_debian : rôle-catégorie sans tâches — il ne porte que le flux SSH du
  plan de gestion, sans quoi les nftables générés couperaient l'accès Ansible à
  toute la flotte ; le vrai travail est dans le playbook de groupe.
- hosts_statiques : le plancher /etc/hosts comme CONDITION de l'ordre de
  reconstruction (résolution par nom avant que PowerDNS existe) ; fichier
  entièrement géré, alias d'exposition best-effort.
- resoudre_base / resoudre_annuaire : entrées, sorties (facts), et pourquoi le
  FQDN plutôt que le nom court (fédération + nom canonique pour verify-full).
- serveur_dovecot : les 3 réglages Dovecot 2.4 qui conditionnent la remise
  (static_allow_all_users, mail_inbox_path vide, mail_path par utilisateur) et
  le local-part seul comme chemin commun LMTP/IMAP ; limite mono-domaine.
- serveur_postfix : liens mailstore/milter, recopie de /etc/hosts dans le chroot.
- serveur_rspamd : clé DKIM idempotente ; le domaine signé doit être PUBLIC en
  prod, sinon la signature ne vaut rien pour les MX distants.
- client_backup / serveur_backup : jobs déclaratifs, chiffrement côté client,
  deux pièges (jobs vides = silencieux ; dépôt neuf vide après un from-zero) ;
  hors-nœud n'est pas hors-site.
- serveur_oauth2_proxy : le patron réutilisable Keycloak-devant-n'importe-quoi,
  et pourquoi allow_unverified_email est nécessaire avec un annuaire LDAP.
- serveur_icingaweb2 : modes ldap vs external, écoute à restreindre en SSO.
- client_unbound : le garde-fou de bascule (apply ET confirm, validation réelle
  avant de toucher /etc/resolv.conf).

docs/carte-set-ops.md ne décrivait plus l'état du code :
- expose EST consommé au déploiement (annoncé comme « Phase 3 à venir ») :
  expositions_des_applications + expositions.conf.j2, alias /etc/hosts, SANs
  d'edge dérivés par instancier.py ;
- 3 mécanismes transverses ajoutés (résolution d'annuaire, plancher de
  résolution, resoudre_base nommé dans les bindings app→base) ;
- 5 entrées d'index ajoutées : réseau/pare-feu, ordre de déploiement,
  preuve/recette, exploitation courante, wiki — pans du corpus non indexés ;
- ce qui reste ouvert est marqué : meta/liens.yml sur le seul serveur_postfix,
  requiert non consommé au déploiement (l'ordre vient des couches + du graphe).

make verifier vert : ansible-lint 514 fichiers, tests, syntax-check,
23 preuves CONFORME / 0 échec / 0 sauté.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-29 11:32:06 -04:00

3.1 KiB

Raw Blame History

serveur_oauth2_proxy

Passerelle SSO générique : place Keycloak devant n'importe quelle application qui n'a pas d'OIDC natif. L'utilisateur s'authentifie une fois auprès de Keycloak ; l'application le reçoit via un en-tête (authentification « external »).

C'est le patron réutilisable qui évite d'écrire une intégration OIDC par application. Éprouvé devant Icinga Web 2.

Comment ça s'assemble

navigateur → edge nginx (TLS) → oauth2-proxy :4180 → application (127.0.0.1:8080)
                                       ↓
                                  Keycloak (OIDC)

L'application passe en auth: external et lit REMOTE_USER, posé par nginx depuis l'en-tête de la passerelle. Elle n'a aucune connaissance d'OIDC.

Rôle

Installe le binaire Go officiel depuis les releases GitHub (pas d'apt), sous /usr/local/bin/oauth2-proxy, avec un utilisateur système dédié.
Déploie la configuration et l'unité systemd, active le service.
Assère d'entrée toute la configuration OIDC obligatoire — pas de démarrage à moitié configuré.

Variables obligatoires (par instance)

Variable	Rôle
`serveur_oauth2_proxy_client_id`	Client OIDC déclaré dans Keycloak
`serveur_oauth2_proxy_client_secret`	Secret du client (voûte)
`serveur_oauth2_proxy_redirect_url`	`https://<app>/oauth2/callback`
`serveur_oauth2_proxy_upstream`	Application protégée (ex. `http://127.0.0.1:8080`)
`serveur_oauth2_proxy_cookie_secret`	32 octets base64 (voûte, `vault_oauth2_cookie`)

Autres variables

Variable	Défaut	Rôle
`serveur_oauth2_proxy_version`	`v7.15.3`	Version épinglée
`serveur_oauth2_proxy_ecoute`	`0.0.0.0:4180`	L'edge proxifie ici
`serveur_oauth2_proxy_realm`	`{{ identite_realm }}`	Realm applicatif
`serveur_oauth2_proxy_issuer`	`https://keycloak.<domaine>/realms/<realm>`	Émetteur OIDC
`serveur_oauth2_proxy_email_domains`	`*`	Tout utilisateur authentifié par Keycloak
`serveur_oauth2_proxy_allow_unverified_email`	`true`	Voir ci-dessous
`serveur_oauth2_proxy_ca_bundle`	`/etc/ssl/certs/ca-certificates.crt`	Racine step_ca (via `client_pki`)

Notes / limites

allow_unverified_email: true est nécessaire ici : les comptes viennent de l'annuaire LDAP, qui ne porte pas de drapeau email_verified. L'IdP est interne et de confiance ; sans ce réglage, aucune connexion ne passe.
La version est épinglée : une montée de version est un geste délibéré (relire les notes de version d'oauth2-proxy, les options changent de nom entre majeures).
Le service écoute en clair sur :4180 — le TLS est terminé à l'edge. À restreindre à l'edge par pare-feu (meta/flux.yml, pair: edge).
Une instance protège une application (upstream unique). Deux applications = deux instances (ou un déploiement par nœud applicatif).

Prérequis

client_pki (confiance step_ca pour joindre Keycloak en HTTPS) et serveur_keycloak actif.
Le client OIDC doit exister dans le realm Keycloak, avec la bonne URL de redirection.

3.1 KiB Raw Blame History