Set-OPS-Public/roles/serveur_icingaweb2/defaults/main.yml
Daniel Allaire 5ecce4282a une console pour le site, et un repli qui ouvrait vers l Internet
Icinga Web 2 gagne un troisieme mode, locale : nginx authentifie en HTTP Basic
et pose REMOTE_USER, l application le croit. Un SITE n a ni annuaire ni Keycloak
— ce sont des services d ecosysteme. Ni backend LDAP ni backend de groupes : un
backend qui vise une ressource inexistante fait echouer chaque ouverture de
session. L habilitation nomme alors une personne, entorse a D-66 ecrite plutot
que contournee.

Deux pieges en chemin : resoudre_annuaire etait appele sans condition et tombait
sur NoneType has no len (default sans son second argument ne remplace pas None),
et le flux du role ne nommait que l edge — le site n en a pas, donc personne ne
pouvait entrer. serveur_grafana portait deja la reponse.

LE DEFAUT DU DEVIS : une sortie vers un role ABSENT de l ecosysteme retombait
sur !SETOPS_INTERNES, la forme de vers l Internet. La frontiere aurait autorise
la console a parler LDAPS a n importe quelle machine du monde, pour joindre un
annuaire qui n existe pas. C est une source vide ouvre le port, cote
destination. Trois regles du meme defaut etaient DEJA posees pour postfix.

La frontiere n est pas ecrite : elle porte la production, et le devis attend un
mot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 19:11:22 -04:00

122 lines
6.2 KiB
YAML

---
# Icinga Web 2 (UI native Icinga) + module IcingaDB, sur le nœud de supervision.
# App PHP servie par nginx local + php-fpm ; l'edge nginx proxifie par nom.
# Auth LDAP direct (OpenLDAP) — icingaweb2 n'a pas d'OIDC natif ; SSO via proxy = raffinement.
serveur_icingaweb2_paquets:
- icingadb-web # module IcingaDB (tire icingaweb2 en dépendance)
- icingaweb2-module-businessprocess # module BPM (vues d'impact métier)
- php8.4-fpm
- php8.4-cli
- php8.4-pgsql
- php8.4-ldap
- php8.4-intl
- php8.4-gd
- php8.4-curl
- php8.4-xml
- php8.4-mbstring
- nginx
serveur_icingaweb2_php_fpm_service: "php8.4-fpm"
serveur_icingaweb2_php_fpm_socket: "/run/php/php8.4-fpm.sock"
serveur_icingaweb2_nginx_service: "nginx"
# Publication : nginx LOCAL sur ce port ; l'edge proxifie icinga.<domaine> ici.
serveur_icingaweb2_hostname: "icinga.{{ domaine_interne }}"
serveur_icingaweb2_http_port: 8080
serveur_icingaweb2_docroot: "/usr/share/icingaweb2/public"
serveur_icingaweb2_config_dir: "/etc/icingaweb2"
# Base IcingaDB (via le registre — même consommateur que le moteur).
serveur_icingaweb2_icinga_groupe: "serveur_icinga"
# Redis IcingaDB (local au nœud de supervision).
serveur_icingaweb2_redis_host: "127.0.0.1"
serveur_icingaweb2_redis_port: 6380
# Authentification LDAP (OpenLDAP, LDAPS). La connexion (url, base, users_dn, bind_dn,
# bind_password) est fournie par le rôle partagé resoudre_annuaire (voir tasks « Adopter la
# connexion annuaire »). Utilisée seulement en mode auth "ldap" ; en SSO, résolue mais inutilisée.
serveur_icingaweb2_ldap_port: 636
serveur_icingaweb2_ldap_user_class: "inetOrgPerson"
serveur_icingaweb2_ldap_user_attr: "uid"
# Qui reçoit le rôle Administrateur (liste d'uid séparés par des virgules).
#
# /!\ NOMMER DES PERSONNES contredit D-66 : révoquer quelqu'un demande alors un
# déploiement, et la liste vieillit sans que rien ne le signale. Icinga Web 2 sait
# lire un groupe d'annuaire (backend LDAP de type `group`) — c'est là qu'il faut
# aller. Voir roles/serveur_icingaweb2/meta/acces.yml.
#
# En attendant, le défaut suit l'`uid` d'amorçage plutôt qu'un compte de test :
# `testmail` était codé en dur et n'existe dans aucune instance — le seul
# administrateur déclaré était donc un utilisateur inexistant (2026-08-07).
# Repli seulement, et VIDE par defaut : l'habilitation passe par le GROUPE
# (`serveur_icingaweb2_groupe_admin`). Le renseigner nomme des personnes, ce que
# D-66 interdit — a n'utiliser que pour un depannage.
serveur_icingaweb2_admins: ""
# Habilitation par groupe d'annuaire. Le schema est celui que `amorcage_acces` pose :
# des `groupOfNames` dont les membres sont des DN.
serveur_icingaweb2_groupe_admin: "{{ amorcage_acces_groupe | default('sysadmin') }}"
serveur_icingaweb2_groupe_class: "groupOfNames"
serveur_icingaweb2_groupe_membre_attr: "member"
serveur_icingaweb2_groupes_dn: "ou=groups,{{ resoudre_annuaire_base_dn | default('') }}"
# Backend d'authentification : "ldap" (direct) ou "external" (utilisateur fourni par une
# passerelle SSO devant, ex. oauth2-proxy → Keycloak). En "external", nginx doit poser REMOTE_USER.
# TROIS MODES D'AUTHENTIFICATION, ET LE TROISIEME EST NE POUR LE SITE (2026-09-14).
#
# `ldap` — connexion directe a l'annuaire. Icinga Web 2 n'a pas d'OIDC natif.
# `external` — une passerelle SSO devant (oauth2-proxy -> Keycloak) pose `REMOTE_USER`,
# et un backend LDAP sert a resoudre les GROUPES.
# `locale` — ni annuaire ni passerelle : nginx authentifie lui-meme, et
# l'habilitation nomme une personne.
#
# POURQUOI `locale` EXISTE. Un SITE n'a ni LDAP ni Keycloak — ce sont des services
# d'ecosysteme, et l'hebergeur n'en est pas un. Sans ce mode, la console de supervision
# du site etait impossible : le plan declarait `serveur_icinga` sans `serveur_icingaweb2`,
# et 88 verdicts se calculaient sans que personne puisse les LIRE.
#
# C'EST LE MEME CHOIX QUE POUR GRAFANA ET FORGEJO au site — `connexion_locale`, un compte
# d'administration, un mot de passe en voute. Nommer une personne contredit D-66 (« le
# GROUPE, jamais des personnes ») ; la regle suppose un annuaire, et il n'y en a pas ici.
# On l'ecrit plutot que de la contourner en silence.
serveur_icingaweb2_auth: "ldap"
# Variable nginx d'où vient REMOTE_USER. En SSO : l'en-tête d'oauth2-proxy.
serveur_icingaweb2_remote_user: "$remote_user"
# Préfixe d'écoute nginx local ("" = toutes interfaces ; "127.0.0.1:" = local, derrière la passerelle).
serveur_icingaweb2_nginx_bind: ""
# Modules icingaweb2 à activer.
serveur_icingaweb2_modules:
- icingadb
- businessprocess
# Processus métier (BPM) à semer, en IaC (nom -> contenu du .conf). Vide par défaut :
# les processus sont normalement édités via l'UI. Un contenu ici est géré par Ansible.
serveur_icingaweb2_bpm_processes: {}
# LES CODES QU'UNE CONSOLE SAINE PEUT RENDRE A UNE REQUETE NON AUTHENTIFIEE.
#
# 200 quand la racine se sert, 302 quand elle renvoie vers le formulaire de connexion,
# 401/403 quand une passerelle SSO se tient devant. Les quatre disent la meme chose : la
# pile PHP est vivante. Ce qu'ils excluent, c'est le 502 et le 504 — php-fpm mort ou
# bloque — et l'absence de reponse, qui est le nginx local tombe.
serveur_icingaweb2_sonde_codes: "HTTP/1.1 200,HTTP/1.1 302,HTTP/1.1 401,HTTP/1.1 403"
# --- MODE `locale` : ce que nginx demande a l'entree ---------------------------------
#
# LE MOT DE PASSE VIENT DE LA VOUTE, comme partout. Vide, le role REFUSE de deployer en
# mode `locale` — degrader, jamais deviner, et surtout jamais un mot de passe par defaut
# sur une console qui montre l'etat de toute une fabric.
serveur_icingaweb2_admin_utilisateur: "icinga-admin"
serveur_icingaweb2_admin_motdepasse: "{{ vault_icingaweb2_admin | default('') }}"
serveur_icingaweb2_htpasswd: "/etc/nginx/.icingaweb2.htpasswd"
serveur_icingaweb2_realm: "Supervision"
# TLS VERS POSTGRESQL, DERIVE DE CE QUE SERT LE SERVEUR. Voir `resoudre_base` et P78.
#
# P78 nommait ce role comme « sans reglage TLS » — c'etait vrai et sans consequence tant
# qu'il ne tournait nulle part face a un `hostssl`. Au site, il en trouve un.
serveur_icingaweb2_db_sslmode: >-
{{ 'verify-full' if (resoudre_base_db_tls_force | default(false)) else '' }}
serveur_icingaweb2_db_sslrootcert: "/etc/step/certs/root_ca.crt"