Sprint 6 — Multi-environnements

Incidents du Sprint 6 : exposition et cloisonnement des environnements dev / staging / prod.

SEC-006 : dev et staging publiquement exposés en clair, branchés sur la base de production

Sévérité : Critical Statut : ✅ Résolu — correctif #146 mergé et validé live le 2026-07-26 (MR !258)

Contexte : Découvert le 2026-07-26 pendant la session de validation live de #136, en répondant à une question sur les certificats — donc totalement hors du périmètre de la tâche en cours. Le multi-env structurel (#134) était en place depuis le 2026-07-25, mais le socle d'isolation ne l'était pas : #137 (databases séparées) et #138 (secrets / DNS / certificats par env) étaient encore ouverts. Une consigne de pilotage disait « ne pas remonter le multi-env en live avant la fin du socle ».

Fichiers : k8s/overlays/{fastapi,frontend}/{dev,staging}/kustomization.yaml, k8s/base/externalsecret.yaml, k8s/platform/gateway.yaml

Symptôme : curl http://dev.api.devopsyouss.com/healthz/ready → 200, en clair, depuis n'importe où sur internet. Idem pour staging.api, dev.app et staging.app.

Cause : Trois briques qui font chacune correctement leur travail, et dont la composition produit un résultat que personne n'a demandé. (1) Le Gateway partagé expose deux listeners, :80 et :443, tous deux en allowedRoutes: from: All — nécessaire, sinon le multi-env cross-namespace ne fonctionne pas. (2) Aucune HTTPRoute du dépôt ne portait de sectionName : or une HTTPRoute sans sectionName s'attache à tous les listeners que le Gateway lui ouvre, pas seulement au bon. (3) ExternalDNS (source gateway-httproute) publie tout hostname rencontré, sans notion d'« environnement pas encore prêt ». Aggravant : les overlays dev et staging ne surchargent pas l'ExternalSecret — le base tire la clé fastapi-eks/app depuis AWS Secrets Manager, la même pour les trois envs, donc dev et staging tapent la base de production. Et le tag de dev est bumpé automatiquement par le write-back à chaque merge sur develop : du code n'ayant passé ni staging ni E2E servait publiquement sur les données de prod. Le risque d'intégrité précédait le risque d'intrusion.

Symptôme trompeur qui a failli faire classer l'affaire : la première alerte n'était pas le 200 en clair, c'était une erreur de certificat sur https://dev.api.devopsyouss.com (le wildcard *.devopsyouss.com ne couvre qu'un seul niveau de label, donc pas dev.api.). On pouvait en conclure « dev est protégé ». Faux : un certificat invalide n'est pas un contrôle d'accès, c'est le client qui décide de l'accepter — et il suffisait d'enlever le s de https pour tout contourner sans le moindre avertissement.

Fix (#146, MR !258) : les 4 overlays de dev et staging suppriment la HTTPRoute héritée du base ($patch: delete) au lieu de lui donner un hostname. Sans route, rien ne s'attache au Gateway et ExternalDNS ne publie aucun enregistrement. Les envs restent joignables par leur Service ClusterIP et par kubectl port-forward. Alternative écartée : garder les routes et restreindre l'accès (allowlist IP, basic auth) — le problème n'est pas « qui accède à dev » mais « dev écrit dans la base de prod », donc une allowlist aurait réduit le nombre de personnes capables de corrompre les données sans supprimer le chemin, tout en ajoutant une configuration à maintenir puis à retirer.

Validation : Mergé puis synchronisé par ArgoCD le 2026-07-26. kubectl get httproute -A ne renvoie plus que 4 routes, toutes en prod ou plateforme (fastapi-prod, frontend-prod, monitoring, argocd) — aucune dans les 4 namespaces dev/staging. Preuve la plus forte côté ExternalDNS, qui dérive ses enregistrements des HTTPRoutes : action=DELETE du CNAME et des deux TXT de propriété (<host> et cname-<host>, marque txtOwnerId=fastapi-eks) pour les 4 hosts, en deux passes de réconciliation. Non-régression prod : curl https://api.devopsyouss.com/healthz/ready → {"status":"ok"}. Accès légitime préservé : port-forward sur fastapi-dev → {"status":"ok"}. Confirmé une seconde fois le 2026-07-28 sur un cluster monté de zéro — cas qui n'avait jamais été exercé, la première validation portant sur un cluster déjà en place : après bootstrap complet et synchronisation ArgoCD, kubectl get httproute -A ne montre aucune route dans les 4 namespaces dev/staging. L'exposition ne se reproduit donc pas au démarrage, qui était précisément le chemin par lequel elle s'était produite.

Leçon : Un garde-fou documentaire n'est pas un contrôle. La consigne « ne pas remonter le multi-env en live avant la fin du socle » existait, et n'a servi à rien : elle n'était écrite nulle part où elle s'appliquait. L'exposition s'est faite toute seule au démarrage du cluster, sans qu'aucun humain ait à agir — ArgoCD synchronise, les routes s'attachent, ExternalDNS publie. C'est la deuxième occurrence du même schéma sur ce projet, après le gate prod « documentaire » (CODEOWNERS en place mais l'approbation obligatoire est payante, donc il suggère sans bloquer). Deux instances indépendantes, ce n'est plus une anecdote : une règle qui dépend de la mémoire d'un humain au bon moment est un vœu, pas un contrôle. Quand on écrit « il ne faut pas faire X », il faut aussitôt se demander qu'est-ce qui empêche X ? — sans réponse, la note ne protège rien. Correctif de fond encore à venir : #137 et #138. Voir le guide Exposition involontaire et l'ADR 029.

SEC-007 : aucune redirection HTTP vers HTTPS, identifiants transmis en clair (production incluse)

Sévérité : High Statut : ✅ Résolu — correctif #147 mergé (MR !257) et validé live le 2026-07-28 sur un cluster monté de zéro

Contexte : Découvert le 2026-07-26 en instruisant SEC-006. Le défaut est antérieur au multi-env : il touche la production, publique depuis le Sprint 4. Le multi-env n'a fait que multiplier la surface, de 2 endpoints à 6.

Fichiers : k8s/base/httproute.yaml, k8s/frontend/httproute.yaml, k8s/platform/argocd/httproute-argocd.yaml, k8s/platform/monitoring/httproute-grafana.yaml, k8s/platform/gateway.yaml

Symptôme : curl http://api.devopsyouss.com/healthz/ready → 200. Les 4 services publics (api, app, grafana, argocd) répondent en clair aussi bien qu'en TLS.

Cause : Même mécanisme que SEC-006 — aucune HTTPRoute ne porte de sectionName, donc toutes s'attachent aux deux listeners du Gateway. Aucun RequestRedirect, aucun ClientTrafficPolicy nulle part dans le dépôt. Le TLS existait et fonctionnait ; rien n'obligeait le client à l'emprunter. C'est une faille et pas un détail de configuration : POST /login accepte identifiants et mot de passe et renvoie un JWT (app/routers/auth.py), et la CLI argocd transporte un token de session. Sur http://, les deux sont lisibles par tout observateur du réseau. CWE-319, Cleartext Transmission of Sensitive Information.

Fix (#147, MR !257) : deux pièces qui ne jouent pas le même rôle. (1) sectionName: https sur les 4 routes applicatives — c'est ceci qui ferme le clair, en les retirant du listener :80. (2) Une HTTPRoute de redirection (k8s/platform/httproute-https-redirect.yaml) sur sectionName: http, sans hostnames donc attrape-tout, avec un filtre RequestRedirect en 301 — elle ne ferme rien, elle offre une sortie propre plutôt qu'un 404 sec, et le 301 est mis en cache par le navigateur. La redirection n'a ni hostname ni backend (un RequestRedirect répond au niveau du Gateway), elle vit donc dans le namespace plateforme fastapi sans y avoir de Service. Posée par le bootstrap Ansible et non en GitOps (ADR 010) : elle décrit le comportement d'un listener, elle appartient à la plomberie du Gateway.

Validation : Hors cluster d'abord — kube-linter sans erreur, kubectl kustomize sur les 6 overlays (le sectionName du base coexiste avec le patch parentRefs/0/namespace des overlays), mkdocs build. Validée en live le 2026-07-28, sur un cluster monté de zéro après merge, ce qui était le point non trivial : la redirection n'étant pas en GitOps, le merge seul ne prouvait rien sur son déploiement.

Les 4 services publics renvoient 301 -> https://<host>/ (api, app, grafana, argocd), là où ils répondaient tous 200 en clair le 2026-07-26. Non-régression du TLS : curl https://api.devopsyouss.com/healthz/ready → {"status":"ok"}. Cause racine fermée et pas seulement son symptôme — kubectl get httproute -A ne montre plus aucune route sans sectionName :

argocd          argocd           https
fastapi-prod    fastapi          https
fastapi         https-redirect   http
frontend-prod   frontend         https
monitoring      grafana          https

Preuve du chemin de déploiement : kubectl get httproute https-redirect -n fastapi renvoie bien la route, sans hostname, posée par le bootstrap Ansible au montage, sans intervention manuelle. ⚠️ Piège de déploiement, toujours valable : sur un cluster déjà monté, un merge ne suffit pas — il faut rejouer le bootstrap ou appliquer le fichier à la main.

Leçon : Le chiffrement disponible n'est pas le chiffrement imposé. Un listener ouvert que personne n'a décidé d'utiliser reste un chemin exploitable, et il suffit d'un caractère en moins dans une URL pour l'emprunter. Corollaire d'architecture propre à Gateway API : un parentRef sans sectionName est un attachement implicite à tout — c'est un défaut par omission, invisible à la relecture d'un manifeste pris isolément, et il faut le chercher activement. Point de vigilance associé : le :80 ne doit désormais plus servir à rien d'autre ; les certificats passent par DNS-01, donc aucun challenge HTTP-01 à préserver, mais un futur ClusterIssuer HTTP-01 serait aveuglé par la route attrape-tout. Voir le guide Exposition involontaire et l'ADR 017 Décision 4.

INC-062 : la rétention ECR a supprimé l'image servie par staging et prod

Sévérité : High Statut : ✅ Résolu — rétention élargie et appliquée, staging et prod repointés, validé live le 2026-07-28 (#150)

Contexte : Découvert le 2026-07-28 en cherchant pourquoi le schedule registry-scan (Phase 1 vuln-mgmt, #118) échouait tous les matins depuis le 2026-07-27. Le job était rouge depuis trois exécutions consécutives sans que personne ne l'ait relié au passage en multi-env du 2026-07-25. Le cluster étant éteint, l'impact réel restait invisible.

Fichiers : terraform/modules/ecr/main.tf, terraform/persistent/variables.tf, k8s/overlays/{fastapi,frontend}/{staging,prod}/kustomization.yaml

Symptôme : Le job registry-scan échoue avec MANIFEST_UNKNOWN: Requested image not found sur deployed-de3dcf4e..., le tag référencé par l'overlay de prod. L'inventaire ECR confirme qu'il ne reste que 5 tags deployed-, tous poussés dans la même soirée du 2026-07-26 entre 17h15 et 20h41. L'image de prod n'existe plus, ni dans fastapi-eks/fastapi, ni dans fastapi-eks/frontend.

Cause : La lifecycle policy ECR conserve les N dernières images portant le préfixe deployed- (deployed_retention_count, alors à 5). Le découpage deployed- / candidate- mis en place en #104 protège l'image servie contre la règle d'âge des candidates, mais pas contre le count : les trois environnements référencent des tags du même moule et concourent donc dans la même fenêtre de rétention. Or leurs cadences sont opposées. Dev est bumpé automatiquement à chaque merge sur develop (write-back reciblé en #139), tandis que staging et prod restent figés entre deux promotions délibérées (scripts/promote.sh, ADR 029 D2). Le 2026-07-26 au soir, cinq merges en trois heures et demie ont suffi à faire sortir l'image de prod de la fenêtre. Aggravant : comme la règle 1 réclamait cette image, son expiration a emporté l'image entière, donc aussi son tag candidate- jumeau — il n'y a rien à retaguer, le digest a disparu.

Fix (#150) : deployed_retention_count porté de 5 à 30, puis terraform apply sur le stack persistent (appliqué en local, la CI infra ne gère que terraform/ephemeral). Il faut corriger la rétention avant de promouvoir, sinon les deux merges de promotion consomment eux-mêmes deux places et l'image fraîchement promue se retrouve à trois merges de l'éjection. Staging et prod sont ensuite repointés sur deployed-e9f2fd64..., seule cible saine encore présente, par deux MR de promotion successives (dev vers staging, puis staging vers prod). Solution écartée pour l'instant : marquer l'image à la promotion avec un préfixe dédié (inuse-<env>-<sha>) protégé par une règle en priorité 1. C'est le seul fix qui ferme réellement le trou, mais il impose un nouveau job CI qui pose un tag ECR au merge de la MR de promotion, promote.sh ne parlant qu'à Kustomize. Un tag mobile type inuse-prod est impossible, les deux repos sont en IMMUTABLE.

Validation : Faite en live le 2026-07-28 au montage du cluster. Les six workloads démarrent, aucun ImagePullBackOff, et kubectl get events -A --field-selector reason=Failed | grep -i pull ne renvoie rien. Les images réellement servies correspondent aux overlays :

fastapi-prod     …/fastapi:deployed-340a8e92…
fastapi-staging  …/fastapi:deployed-340a8e92…
frontend-prod    …/frontend:deployed-340a8e92…
frontend-staging …/frontend:deployed-340a8e92…
fastapi-dev      …/fastapi:deployed-905509fb…
frontend-dev     …/frontend:deployed-905509fb…

Rétention vérifiée côté AWS après apply : countNumber = 30 sur la règle 1 des deux dépôts. Le compteur de tags deployed- est passé de 5 à 7 pendant la session — sous l'ancienne valeur, les merges de la journée auraient supprimé deux images de plus. Reste à confirmer : registry-scan ne pourra repasser au vert qu'au prochain schedule du matin avec le ci_config_path rebasculé sur l'application. Le tag qu'il cherche, deployed-340a8e92, est présent dans les deux dépôts.

Leçon : Un mécanisme de protection reste valide tant que ses hypothèses le sont. Le découpage de #104 était correct en mono-environnement, où l'image servie était toujours la dernière produite, donc structurellement en tête de fenêtre et jamais menacée par un count. Le passage en multi-env a supprimé cette propriété sans que personne ne relise la règle, parce que le changement portait sur Kustomize et ArgoCD, pas sur Terraform. La revue d'impact d'un changement d'architecture doit descendre jusqu'aux garde-fous écrits pour l'architecture précédente, y compris ceux qui vivent dans une autre couche de la stack. Corollaire opérationnel : une politique de rétention de registre ne sait pas ce qui tourne dans le cluster, elle ne connaît que des dates et des compteurs. Tant qu'aucun tag ne distingue l'image en service, élargir la fenêtre rend l'incident improbable sans le rendre impossible. Et le seul signal qui a levé le lièvre était un job de scan rouge, symptôme indirect : sans lui, le problème serait apparu au prochain démarrage du cluster, sous la forme d'une prod qui ne démarre pas.

INC-063 : plus aucune métrique de l'API collectée depuis le cutover multi-env

Sévérité : High Statut : ✅ Résolu — correctif #152 mergé (MR !268) et validé live le 2026-07-28

Contexte : Découvert le 2026-07-28 en validant #135, par un contrôle de non-régression. Le correctif NetworkPolicy restreignait l'ingress de l'API à Envoy et Prometheus ; il fallait donc vérifier que Prometheus scrapait toujours. La requête a renvoyé zéro cible, ce qui a d'abord ressemblé à une régression du correctif.

Fichiers : k8s/platform/monitoring/servicemonitor-fastapi.yaml, k8s/platform/monitoring/prometheusrules-fastapi.yaml

Symptôme : /api/v1/targets ne renvoie aucune cible dont le namespace commence par fastapi. En parallèle, l'alerte FastAPITargetMissing est en firing / critical depuis le démarrage du cluster.

Cause : Le ServiceMonitor portait namespaceSelector.matchNames: [fastapi]. Or le cutover multi-env (#134, 2026-07-25) a fait de fastapi un namespace plateforme qui n'héberge plus que le Gateway : il ne contient aucun Service. Les Services applicatifs vivent désormais dans fastapi-dev, fastapi-staging et fastapi-prod, tous correctement labellisés app: fastapi. Le sélecteur pointait donc sur un namespace vide. Aggravant : les règles PrometheusRule sont épinglées sur le même namespace="fastapi", donc FastAPITargetDown et FastAPIPodCrashLooping étaient elles aussi inertes. Et les deux alertes RED n'avaient aucun filtre de namespace : réparer le seul scrape aurait fait paginer un pic d'erreurs de dev comme s'il venait de la prod.

Écart de diagnostic à retenir : une NetworkPolicy qui bloque un scrape laisse la cible visible en down, avec un lastError. Zéro cible signifie que la découverte de service n'a rien trouvé, ce qui se situe en amont du réseau. C'est ce raisonnement qui a disculpé #135 en une minute au lieu d'un revert inutile.

Fix : namespaceSelector: {any: true} sur le ServiceMonitor, et non une nouvelle liste de namespaces — reconduire une liste figée, c'est reprogrammer la même panne au prochain changement de topologie. Le couple any: true + selector: app=fastapi suit les Services où qu'ils aillent, et le label namespace reste porté par chaque série. Les 5 règles d'alerte sont recentrées sur fastapi-prod : on page sur ce qui sert les utilisateurs. L'alerting par environnement relève de #141.

Validation : Faite en live le 2026-07-28, juste après le merge. Les 5 cibles apparaissent, une par pod, sur les trois environnements, toutes en up :

fastapi-dev     | up
fastapi-prod    | up
fastapi-prod    | up
fastapi-staging | up
fastapi-staging | up

FastAPITargetMissing a cessé de sonner ; il ne reste que Watchdog et les deux alertes d'overcommit, attendues. Étape intermédiaire instructive : à la découverte, les cibles sont apparues en unknown — elles existent mais n'ont pas encore été scrapées. C'est un troisième état, distinct de up et de down, qu'il faut savoir attendre (intervalle 30s) avant de conclure à un échec. Références résiduelles à l'ancienne topologie nettoyées dans docs/validation-runbook.md et docs/comprendre/alerting.md.

Leçon : Un garde-fou peut fonctionner parfaitement et ne servir à rien. FastAPITargetMissing a été écrite exactement pour ce cas — son commentaire dit « absent() renvoie 1 quand la série est introuvable => couvre ce trou » — et elle a correctement sonné en critical pendant les trois jours d'uptime qui ont suivi le cutover. Ce qui a manqué, c'est le regard sur l'alerte, pas l'alerte. Une chaîne de détection ne vaut que par son dernier maillon, qui est humain. Corollaire de conception : un sélecteur qui nomme explicitement une ressource (matchNames, un namespace en dur dans une expr) crée une dépendance silencieuse à la topologie — il ne casse pas quand elle change, il cesse de faire son travail. C'est la troisième occurrence du motif sur ce sprint après SEC-006 et INC-062 : un changement d'architecture doit être suivi jusque dans les objets écrits pour l'architecture précédente, même quand ils vivent dans une autre couche.

INC-064 : `trivy-image-scan` rouge sur deux CVE d'outillage jamais installé

Sévérité : High Statut : ✅ Résolu — correctif #155

Contexte : Découvert le 2026-07-30 en ouvrant !271 (#137), dont le pipeline est tombé rouge alors que la MR ne touche ni Dockerfile, ni requirements.txt, ni aucun fichier Python. Le même code applicatif passait au vert le 2026-07-28 à 18:45 (pipeline 2713010874, sha 332fcf1c), et l'image de base est pinnée par digest : elle n'avait pas bougé. !271 a été mergée malgré ce rouge, l'échec étant prouvé indépendant, ce qui a laissé develop rouge sur ce job.

Fichiers : Dockerfile, .dockerignore

Symptôme : trivy-image-scan échoue sur l'image backend avec deux vulnérabilités de sévérité haute : msgpack 1.1.2 (GHSA-6v7p-g79w-8964, corrigé en 1.2.1) et setuptools 70.3.0 (CVE-2025-47273, corrigé en 78.1.1). Ni l'un ni l'autre n'apparaît dans requirements.txt, et la trace du job ne donne pas leur PkgPath.

Cause : Aucun des deux paquets n'est installé dans l'image. Trivy les lit dans pip/_vendor/vendor.txt, le manifeste des dépendances vendorisées de pip, qu'il interprète comme un inventaire de paquets installés — d'où le PkgPath vide. L'image portait deux pip : celui de l'image de base (25.0.1, qui déclare msgpack==1.1.0) et celui du venv, monté en 26.2 par la ligne pip install --no-cache-dir --upgrade pip wheel du stage builder puis recopié tel quel par COPY --from=builder /venv /venv (qui déclare msgpack==1.1.2). La mise à jour de la base de vulnérabilités de Trivy a fait franchir le seuil à ces deux lignes : la CVE est arrivée au monde, pas au projet. Le commentaire du Dockerfile affirmait déjà « ni pip, ni outils de build » — il décrivait une intention, pas l'image réellement produite.

Écart de diagnostic à retenir : le bump du digest de base, première voie envisagée dans l'issue, n'aurait rien corrigé. Le pip fautif est installé par le Dockerfile lui-même, pas hérité de la base, et le pip de la base vendorise une version de msgpack également sous le seuil. Un PkgPath vide dans un rapport Trivy n'est pas un détail cosmétique : il signale que le paquet n'a pas de dist-info, donc qu'il n'a jamais été installé.

Fix : Suppression de pip et wheel du stage runtime (venv et site-packages de la base), plutôt qu'une exception VEX. Rien n'installe de paquet à l'exécution, la suppression est donc sans effet fonctionnel et retire la cause au lieu d'annoter le symptôme — une exception VEX aurait dû être réécrite à chaque future CVE d'une dépendance vendorisée de pip. Corrigé dans la foulée : frontend/ n'était pas dans .dockerignore, donc la source du frontend partait dans l'image backend, et tout node_modules présent dans le workspace de build y aurait injecté ses propres CVE.

Validation : Faite en local sur l'image buildée depuis le Dockerfile corrigé, avec les flags exacts du job CI (gate --exit-code 1 sur les sévérités hautes et au-dessus, --ignore-unfixed, --ignorefile .trivyignore, --vex) : le gate sort en 0, contre deux vulnérabilités hautes avant. Non-régression applicative vérifiée sur la même image : import app.main passe, uvicorn démarre, /healthz/live et /docs répondent 200. Effet de bord mesuré : 269 Mo → 234 Mo, l'essentiel venant de l'exclusion du frontend. Confirmation attendue par le trivy-image-scan de develop après merge.

Leçon : Un scanner rapporte ce qu'il sait lire, pas ce qui est installé. Trivy déduit un inventaire de fichiers manifestes, et vendor.txt en est un sans qu'aucun paquet ne soit déployable derrière. Prendre le rapport pour l'état réel de l'image conduit à traiter une remontée là où elle est affichée plutôt que là où elle naît — ici, à bumper une image de base qui n'y était pour rien. Le réflexe utile est de localiser physiquement le paquet dans l'image avant de choisir le traitement : c'est ce qui a fait apparaître qu'il n'y avait rien à corriger, seulement de l'outillage à ne pas embarquer. Second enseignement, sur le rouge lui-même : un job de scan peut virer sans qu'une seule ligne du dépôt ait changé, puisque son verdict dépend d'une base de données externe et mouvante. Un pipeline rouge n'est donc pas toujours une régression, et l'écart entre le dernier vert connu et le premier rouge est la première mesure à faire.