Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
Set-OPS-Public/roles/serveur_postgresql
History
Daniel Allaire f3bb9caee3 chiffrement : metriques et journaux du site en TLS, et la frontiere certifiee par sa propre autorite 
Metriques et journaux (CHANGELOG 142). Le site pose les quatre interrupteurs TLS
que chaque locataire pose dans ses group_vars : node_exporter et Loki servaient
en HTTP sur les neuf VM, le certificat etait la, inutilise. test_parite_tls_site.py
compare desormais le site aux locataires. Les hyperviseurs poussent leurs
journaux en HTTPS verifie, avec la racine du site comme simple fichier.
L'exportateur PostgreSQL sert en HTTPS partout, sur l'interrupteur de PostgreSQL
lui-meme, que Prometheus lit pour choisir son schema.

La frontiere (CHANGELOG 143). Une autorite subordonnee signee par la racine du
site, bornee (pathlen 0, noms sous le domaine et adresses du site, contrainte
critique), cle nee sur la boite (scripts/frontiere_pki.py). Syslog vers Loki en
TLS mutuel (seule la frontiere peut ecrire), exportateur en HTTPS, interface web
sur le certificat de services ; les clients d'API verifient la frontiere contre
la racine du site. La lecture du magasin passe par config.xml : l'API de
recherche renvoie les cles privees.

Deploye et mesure au site, chez les deux locataires et sur la frontiere ; 95 preuves.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 14:25:28 -04:00
..
defaults chiffrement : metriques et journaux du site en TLS, et la frontiere certifiee par sa propre autorite 2026-10-12 14:25:28 -04:00
handlers meta/metriques.yml : le role declare son exportateur, le moteur derive 2026-09-14 11:35:14 -04:00
meta chiffrement : metriques et journaux du site en TLS, et la frontiere certifiee par sa propre autorite 2026-10-12 14:25:28 -04:00
tasks chiffrement : metriques et journaux du site en TLS, et la frontiere certifiee par sa propre autorite 2026-10-12 14:25:28 -04:00
templates chiffrement : metriques et journaux du site en TLS, et la frontiere certifiee par sa propre autorite 2026-10-12 14:25:28 -04:00
README.md Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00

README.md

serveur_postgresql

Installe et configure PostgreSQL (paquet Debian 13) comme base relationnelle partagée interne.

Rôle

  • Installe postgresql, postgresql-contrib et python3-psycopg2.
  • Détecte le cluster installé par Debian (/etc/postgresql/<version>/main).
  • Configure via un fichier conf.d/99-setops.conf : listen_addresses, port, password_encryption.
  • Gère pg_hba.conf : socket local en peer (administration), boucle locale et réseaux internes autorisés en scram-sha-256.
  • Active et démarre le service.
  • Provisionne optionnellement comptes et bases applicatifs (vides par défaut).

Réseau et sécurité

  • Écoute par défaut sur 127.0.0.1 et l'IP interne de l'hôte (ansible_host).
  • serveur_postgresql_reseaux_autorises ouvre l'accès aux clients internes (défaut 10.0.0.0/16).
  • Authentification scram-sha-256 (jamais md5/trust).
  • pg_hba.conf et la conf sont entièrement gérés par le rôle ; les modifications manuelles sont écrasées.

Variables principales

Variable Défaut Rôle
serveur_postgresql_version "" (auto) Version majeure du cluster
serveur_postgresql_port 5432 Port d'écoute
serveur_postgresql_ecoute 127.0.0.1 + IP interne listen_addresses
serveur_postgresql_reseaux_autorises ["10.0.0.0/16"] Réseaux clients en pg_hba
serveur_postgresql_methode_auth scram-sha-256 Méthode d'authentification
serveur_postgresql_parametres {} Réglages additionnels
serveur_postgresql_comptes [] Comptes applicatifs (mot de passe via Vault)
serveur_postgresql_bases [] Bases applicatives

Provisionnement applicatif

À déclarer quand un service en a besoin, mots de passe depuis Ansible Vault :

serveur_postgresql_comptes:
  - nom: keycloak
    mot_de_passe: "{{ vault_postgresql_keycloak }}"
serveur_postgresql_bases:
  - nom: keycloak
    proprietaire: keycloak

Registre partagé des bases applicatives

En plus des listes explicites, le rôle lit instance/plan/bases-donnees.yml (registre déclaratif) et crée chaque base + son compte propriétaire dont serveur vaut serveur_postgresql. Le mot de passe vient de la variable Vault nommée par le champ secret. Le rôle applicatif lit le même registre pour bâtir sa chaîne de connexion — secret partagé, source unique. Patron : 1 appli → 1 base → 1 owner → 1 chaîne de connexion. Voir l'en-tête de instance/plan/bases-donnees.yml.

Prérequis

  • Collection community.postgresql (ansible-galaxy collection install community.postgresql).

Hors périmètre

  • Sauvegardes (rôle/concern séparé), réplication, tuning avancé.