Les rôles à secrets déclaraient serveur_X_password: "" avec la variable
de voûte seulement en commentaire — aucun mapping réel. Remplir la voûte
ne branchait donc rien (secret vide → assertion échoue).
Les 12 secrets des 8 rôles pointent maintenant vers leur source :
serveur_X_password: "{{ vault_X | default('') }}"
Comportement inchangé si la voûte est vide ; branché dès qu'elle a le
secret. Prouvé : assertion step_ca passe avec vault_step_ca_password.
Chaque instance remplit ses vault_* ; aucun mapping par instance.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_redis
Cache / files Redis (paquet Debian) sur le nœud données (data-01), aux côtés de PostgreSQL.
Rôle
- Installe
redis-server. - Déploie une surcharge
/etc/redis/setops.conf(incluse en fin deredis.conf, donc prioritaire) : écoute,requirepass,maxmemory+ politique d'éviction. - N'écrase pas le
redis.confdu paquet (approche non destructive parinclude).
Sécurité
- Exposé sur le réseau interne (
127.0.0.1+ IP interne) → mot de passe obligatoire (requirepass, depuis Vault).protected-mode yes. - L'accès reste restreint par la segmentation réseau (VLAN données / nftables).
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_redis_ecoute |
127.0.0.1 + IP interne |
Adresses d'écoute (bind) |
serveur_redis_maxmemory |
256mb |
Limite mémoire |
serveur_redis_maxmemory_policy |
allkeys-lru |
Éviction (cache) |
serveur_redis_password |
"" (Vault requis) |
requirepass |
Intégration
- Consommé par les applis qui ont besoin d'un cache (Nextcloud, etc.) via leur chaîne de connexion Redis (hôte data-01, port 6379, mot de passe).
Hors périmètre
- Réplication / Sentinel / Cluster, persistance avancée (AOF tuning), TLS.