Aller au contenu

Mail Gateway

Le namespace mail-system fournit le point de sortie e-mail commun du cluster. Il n'est pas exposé publiquement : les applications l'appellent via le Service interne http://mail-gateway.mail-system.svc.cluster.local:8080.

État actuel

Application Routage Identité caller État
moncouple provider historique partagé namespace autorisé actif
maintenance provider historique partagé namespace autorisé actif
alerting provider historique partagé namespace autorisé actif
notrecouple provider SMTP dédié X-Mail-Caller-Token obligatoire actif

Le Deployment déclare actuellement moncouple,maintenance,alerting,notrecouple dans ALLOWED_APPS. Le namespace notrecouple existe et porte mail-gateway-access: "true". NotreCouple utilise donc réellement le gateway ; il n'est plus dans l'état « câblé mais non activé » des premières PR de fondation.

Frontière d'accès

La chaîne est :

workload autorisé
  -> NetworkPolicy / label mail-gateway-access=true
  -> mail-gateway.mail-system.svc.cluster.local:8080
  -> sélection du provider
  -> SMTP

Aucun credential SMTP n'est copié dans un namespace applicatif. Les Secrets de provider restent dans mail-system.

Pour les applications à provider dédié, X-Mail-App ne suffit pas comme preuve d'identité. Le gateway exige aussi X-Mail-Caller-Token et compare sa valeur en temps constant avant toute sélection du provider. Un token absent, vide ou invalide échoue en 401 caller_not_authorized.

NotreCouple possède deux côtés du même contrat hors Git :

  • le vérificateur dans mail-system/mail-gateway-notrecouple-caller ;
  • le caller dans notrecouple/notrecouple-mail.

Les workloads NotreCouple injectent cette identité lorsqu'ils appellent le Mail Gateway ; le panneau admin réutilise le même contrat pour les e-mails administratifs autorisés.

Providers SMTP

Le provider historique utilise le Secret mail-gateway-smtp. Le provider NotreCouple utilise mail-gateway-notrecouple-smtp.

Les Secrets SMTP suivent les clés :

  • SMTP_HOST ;
  • SMTP_PORT ;
  • SMTP_USER ;
  • SMTP_PASSWORD ;
  • SMTP_FROM ;
  • SMTP_STARTTLS ;
  • SMTP_SSL.

Le provider historique actuellement documenté est le relais Brevo sur smtp-relay.brevo.com:587 avec STARTTLS. NotreCouple conserve un provider dédié au domaine notrecouple.fr afin de ne pas permettre à un autre appelant de sélectionner son identité d'envoi.

La configuration est fail-closed : si le provider dédié est sélectionné mais incomplet, l'appel échoue en 503 smtp_provider_not_configured. Il ne retombe jamais sur le provider historique.

API

  • GET /healthz : santé du processus et état de configuration des providers/caller tokens ;
  • GET /readyz : disponibilité opérationnelle du gateway ;
  • GET /metrics : métriques Prometheus ;
  • POST /send : envoi synchrone après validation de l'application et de l'identité caller lorsqu'elle est requise.

Exemple pour un caller partagé :

POST /send
X-Mail-App: maintenance
Content-Type: application/json

{
  "to": "destinataire@example.net",
  "subject": "Sujet",
  "text": "Corps"
}

Un caller NotreCouple ajoute en plus X-Mail-Caller-Token. La valeur n'est jamais documentée ni journalisée.

Supervision

Gatus vérifie GET /readyz via le Service interne. Prometheus expose notamment l'état des providers et des caller tokens configurés ainsi que les compteurs d'échec.

Points à distinguer :

  • gateway historique indisponible : impact transversal, incident prioritaire ;
  • provider dédié NotreCouple non configuré : les e-mails NotreCouple échouent, sans bascule vers un autre expéditeur ;
  • caller token manquant/invalide : rejet 401, ce qui indique un problème d'identité applicative et non un problème SMTP.

Exploitation

kubectl -n mail-system get deploy,pod,svc
kubectl -n mail-system logs deploy/mail-gateway --tail=100
kubectl -n mail-system exec deploy/mail-gateway -- wget -qO- http://127.0.0.1:8080/healthz
kubectl -n mail-system exec deploy/mail-gateway -- wget -qO- http://127.0.0.1:8080/readyz

Pour contrôler les Secrets sans lire leurs valeurs :

kubectl -n mail-system describe secret mail-gateway-smtp
kubectl -n mail-system describe secret mail-gateway-notrecouple-smtp
kubectl -n mail-system describe secret mail-gateway-notrecouple-caller
kubectl -n notrecouple describe secret notrecouple-mail

Après rotation d'un Secret, redémarrer le gateway si la valeur consommée n'entraîne pas déjà un rollout GitOps :

kubectl -n mail-system rollout restart deployment/mail-gateway
kubectl -n mail-system rollout status deployment/mail-gateway

Ajouter un consommateur

  1. Ajouter le label mail-gateway-access: "true" à son namespace.
  2. Ajouter son identifiant dans ALLOWED_APPS.
  3. Pour un provider partagé, appeler /send avec X-Mail-App.
  4. Pour un provider dédié, créer le Secret SMTP et un Secret de caller hors Git, déclarer le provider dans le gateway et injecter le même token côté workload.
  5. Ajouter les tests négatifs d'usurpation avant activation.
  6. Mettre à jour le wiki, le catalogue et la supervision si une nouvelle surface opérable apparaît.

Ne jamais rendre un provider dédié sélectionnable uniquement sur la base de X-Mail-App.

Sécurité

  • aucun Ingress public ;
  • NetworkPolicy d'entrée ;
  • credentials SMTP confinés à mail-system ;
  • token de caller hors Git ;
  • comparaison en temps constant ;
  • refus avant sélection des credentials en cas d'identité invalide ;
  • aucun fallback silencieux d'un provider dédié vers le provider partagé.