Version : 1.0 — 28/07/2026
Public : Support N2 (accès bastion + kubectl contexte RKE2)
Références : rapport INC-RBER-2026-07-23 (mail down 4 jours — lire avant d'intervenir)
| Élément | Valeur |
|---|---|
| Serveur mail | Stalwart (SMTP/IMAP/JMAP tout-en-un) |
| Namespace RKE2 | RENSEIGNER_NS_STALWART |
| Exposition | Hors reverse proxy — service LoadBalancer MetalLB 10.29.113.210, NAT 1:1 vers IP publique dédiée 102.222.216.9 |
| Justification archi | SPF/DKIM/PTR exigent une IP publique dédiée ; le passthrough HAProxy est inadapté aux protocoles mail |
| Base de données | Cluster CNPG stalwart-pg (namespace RENSEIGNER_NS_STALWART) — stocke config, comptes, et les bannissements fail2ban |
| Image | Épinglée par digest depuis l'incident du 23/07 (interdiction :latest — changements de format de config entre versions mineures) |
| Ports | 25 (SMTP), 465 (submission SSL), 993 (IMAPS), 443 (JMAP/webadmin) |
| DNS | MX mail.rber.bj → 102.222.216.9 ; SPF/DKIM en place ; PTR pas encore posé (délivrabilité dégradée possible vers certains fournisseurs) |
Toujours dans cet ordre. Contexte RKE2 (kubectl config current-context d'abord).
# 1. État des pods
kubectl -n RENSEIGNER_NS_STALWART get pods -o wide
# 2. État de la base (le premier suspect — cf. incident 23/07)
kubectl -n RENSEIGNER_NS_STALWART get clusters.postgresql.cnpg.io
# Attendu : "Cluster in healthy state", instances 2/2 ou 3/3
# 3. Le service LoadBalancer a-t-il une IP et des endpoints ?
kubectl -n RENSEIGNER_NS_STALWART get svc
kubectl -n RENSEIGNER_NS_STALWART get endpoints
# 4. L'IP MetalLB est-elle annoncée ? (précédent : wrk-02 exclu du L2Advertisement)
kubectl -n metallb-system get l2advertisement -o yaml
# Vérifier qu'AUCUN worker n'est exclu sans justification documentée
# 5. Test réseau depuis le bastion
nc -vz 10.29.113.210 25
nc -vz 10.29.113.210 993
# 6. Test depuis l'extérieur (4G ou VPS)
nc -vz mail.rber.bj 25
# 7. Logs applicatifs
kubectl -n RENSEIGNER_NS_STALWART logs deploy/RENSEIGNER_DEPLOY_STALWART --tail=100
Arbre de décision :
| Constat | Cause probable | Action |
|---|---|---|
| Pod CrashLoopBackOff, log « parse error » ou erreur config | Base injoignable ou identifiants désalignés — le message ment (précédent 23/07) | §3 |
| Cluster CNPG non healthy | Problème PG | §4 |
| Pods OK, endpoints OK, mais port fermé depuis l'extérieur seulement | Annonce MetalLB ou NAT firewall | §5 |
| Utilisateur précis rejeté à l'authentification | fail2ban | §6 |
| Tout OK mais mails en spam chez les destinataires | Délivrabilité SPF/DKIM/PTR | §7 |
stalwart en base. Couplage manuel connu entre le secret CNPG app et l'utilisateur applicatif — un rollback/restauration PG peut désaligner les deux (précédent 23/07).kubectl -n RENSEIGNER_NS_STALWART get secret stalwart-pg-app -o jsonpath='{.data.password}' | base64 -d
# Comparer avec le mot de passe dans la config Stalwart / tester la connexion PG
kubectl -n RENSEIGNER_NS_STALWART exec stalwart-pg-1 -- psql -U stalwart -c "SELECT 1"
kubectl -n RENSEIGNER_NS_STALWART get pods -o jsonpath='{range .items[*]}{.spec.containers[0].image}{"\n"}{end}'
Stalwart stocke ses bans en base PostgreSQL (tables à nom court, colonnes bytea).
# Lister les bans
kubectl -n RENSEIGNER_NS_STALWART exec stalwart-pg-1 -- psql -U stalwart -d stalwart \
-c "RENSEIGNER_REQUETE_LISTE_BANS" # à figer après vérification du schéma en place
[authentication.fail2ban.whitelist]) : 10.42.0.0/16 et 10.43.0.0/16 (sinon l'Ingress Controller se fait bannir et bloque tout le monde). Vérifier qu'elle est en place à chaque intervention.nslookup -type=TXT rber.bj — doit inclure 102.222.216.9.nslookup -type=TXT RENSEIGNER_SELECTEUR._domainkey.rber.bj.nslookup 102.222.216.9 — doit renvoyer mail.rber.bj. État actuel : PTR non posé — si un fournisseur rejette pour ce motif, remonter la priorité du PTR à N3 (dépend de l'opérateur de l'IP).last-applied-configuration — incident précédent). Secrets K8s uniquement.