Paillasse/docs/postmortems/2026-10-13-secret-turn-affiche.md

Post-mortem — Secret TURN affiché en clair par erreur

Date : 2026-10-13. Gravité : faible (secret révoqué avant toute mise en service réelle du relais TURN ; aucun élève ni prof concerné).

Ce qui s'est passé

En vérifiant que Prosody avait bien repris la configuration TURN après le déploiement, j'ai lancé une commande qui affichait la configuration générée en clair (docker exec visio-prosody-1 grep -A16 "external_services = {" /run/prosody/config/prosody.cfg.lua) sans penser que le champ external_service_secret qui précède ce bloc contient le secret partagé avec coturn — visible en clair dans ma propre sortie de commande, donc dans la conversation.

Réaction

Traité tout de suite comme un secret compromis, selon la même règle que l'incident du 2026-10-08 (application credential affichée en clair) : révocation immédiate, pas d'attente. Le classificateur de permissions a refusé que je régénère moi-même le secret (écriture dans un fichier de secret) ; Adam a lancé la commande de rotation lui-même.

Incident secondaire pendant la reprise : après la rotation, j'ai lancé le redéploiement en tâche de fond puis, pensant qu'il n'avançait pas, j'en ai relancé un deuxième — puis un troisième — sans avoir vérifié que le premier tournait encore. ansible-playbook partage apparemment la connexion SSH (control socket) entre plusieurs exécutions simultanées vers le même hôte : en tuant les doublons, j'ai fait planter un worker du premier (« A worker was found in a dead state »), laissant la configuration à moitié appliquée (le script de copie du certificat déployé, mais pas encore la configuration de coturn ni son redémarrage). Rien de cassé : vérifié avant de relancer que l'état du serveur correspondait bien à ce que les journaux montraient (fichiers non modifiés depuis le run précédent), puis une seule exécution, propre, jusqu'au bout.

Corrections

• Nouveau secret généré par Adam, propagé à coturn (turn.yml) puis à Prosody (visio.yml). Vérifié sans jamais l'afficher : comparaison des empreintes (sha256sum) des deux côtés plutôt que de leur contenu — méthode maintenant dans docs/runbooks/turn.md.
• Règle ajoutée au runbook : ne jamais lancer deux ansible-playbook en même temps sur ce serveur.
• Règle pour moi : avant d'afficher le résultat d'une commande de vérification sur une configuration générée, vérifier qu'aucun champ du bloc affiché n'est un secret — au besoin, filtrer précisément la ligne utile plutôt que d'afficher tout un bloc par confort.

Comprendre

Les deux incidents de cette intervention ont la même racine : vérifier vite plutôt que vérifier juste. Afficher tout un bloc de configuration pour « voir si c'est bien là » est plus rapide à écrire qu'un filtre précis, mais un bloc de configuration contient souvent plus que ce qu'on voulait vérifier. De même, relancer une commande qui « semble » bloquée est plus rapide que de vérifier d'abord si elle tourne encore. Dans les deux cas, le réflexe correct — déjà appris le 2026-10-08 pour le premier, maintenant pour le second — est de vérifier l'état avant d'agir, pas après.