# =============================================================================
# Redis 7 - production Xpeditis
# =============================================================================
# Le mot de passe n'est PAS ici : il est injecte par --requirepass depuis
# .env.data (cf. docker-compose.data.yml). Ce fichier est versionne, pas lui.

# --- Reseau ------------------------------------------------------------------
# Ecoute sur toutes les interfaces DU CONTENEUR ; l'exposition reelle est
# limitee par Docker (bind sur l'IP privee) puis par UFW.
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
tcp-keepalive 300
timeout 300

# --- Persistance -------------------------------------------------------------
# Redis ne sert pas qu'a cacher les cotations : il porte aussi des donnees de
# session et de revocation de jetons. Un redemarrage ne doit pas les perdre,
# sinon des jetons revoques redeviendraient valides.
dir /data
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes

# --- Memoire -----------------------------------------------------------------
# Estimation Excel : 0,5 Go a 100 utilisateurs. On plafonne a 1 Go, soit 2x de
# marge, sous la limite conteneur de 1,5 Go.
#
# volatile-lru et non allkeys-lru : seules les cles portant un TTL peuvent etre
# evincees. Les cotations tarifaires (TTL 15 min) sont donc sacrifiables, ce qui
# est le comportement voulu. Surveiller quand meme used_memory : une eviction
# subie sur une cle de revocation prolongerait la validite d'un jeton revoque.
# Alerte Grafana a 75 % (cf. k8s/monitoring/).
maxmemory 1gb
maxmemory-policy volatile-lru
maxmemory-samples 5

lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

# --- Durcissement ------------------------------------------------------------
# Les commandes destructrices ou de reconnaissance sont RENOMMEES, pas
# supprimees : une injection cote application ne peut plus les atteindre, mais
# un operateur qui connait le nom garde une porte de sortie en incident.
#
# Consequence connue : RedisCacheAdapter.clear() (redis-cache.adapter.ts:133)
# appelle FLUSHDB et echouera donc en production. C'est volontaire -- cette
# methode n'a aucun appelant dans le code applicatif et vider le cache de prod
# depuis une requete HTTP ne doit jamais etre possible. Pour vider le cache
# manuellement, utiliser le nom renomme ci-dessous depuis db-01.
#
# Ces noms sont publics dans Git : ils protegent d'une injection, pas d'un
# attaquant ayant deja le mot de passe Redis ET l'acces reseau. Si vous voulez
# une vraie defense, remplacez-les par des chaines aleatoires et notez-les dans
# le coffre-fort.
rename-command FLUSHALL  XPD_FLUSHALL_9c1f
rename-command FLUSHDB   XPD_FLUSHDB_9c1f
rename-command KEYS      XPD_KEYS_9c1f
rename-command CONFIG    XPD_CONFIG_9c1f
rename-command DEBUG     ""
rename-command MODULE    ""

# --- Journalisation ----------------------------------------------------------
logfile ""
loglevel notice

# --- Divers ------------------------------------------------------------------
databases 16
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 100