Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/roles/serveur_oauth2_proxy
History
Daniel Allaire 840b21bfb6 artefacts : le controleur telecharge et pousse, la cible ne tire plus 
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>
2026-08-10 20:58:58 -04:00
..
defaults artefacts : le controleur telecharge et pousse, la cible ne tire plus 2026-08-10 20:58:58 -04:00
handlers serveur_oauth2_proxy : passerelle SSO OIDC générique + Icinga Web 2 au SSO 2026-07-03 19:05:04 -04:00
meta authentification : chaque rôle déclare sa position, gardé par P29 2026-08-03 17:05:43 -04:00
tasks artefacts : le controleur telecharge et pousse, la cible ne tire plus 2026-08-10 20:58:58 -04:00
templates serveur_oauth2_proxy : passerelle SSO OIDC générique + Icinga Web 2 au SSO 2026-07-03 19:05:04 -04:00
README.md docs : un README par rôle (12 manquants) + carte remise à l'état du code 2026-07-29 11:32:06 -04:00

README.md

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.