[infra] Retirer la socket Docker des conteneurs de tâche de la chaîne #103

New issue

Closed

opened 2026-09-03 07:58:45 +00:00 by lenaic · 0 comments

lenaic commented

2026-09-03 07:58:45 +00:00

Owner

Exigence couverte

ENF-14, ENF-11

Épreuve servie

EC03 · CI/CD et qualité

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Retirer la socket Docker des conteneurs de tâche de la chaîne d'intégration. Elle y est montée d'office par la configuration de l'exécuteur, et non déclarée par les workflows : n'importe quelle poussée sur n'importe quelle branche dispose donc d'un accès root sur le serveur, sans rien avoir à demander.

C'est ce qui a permis de rétablir l'accès ce matin, et c'est précisément pour ça que c'est un problème. docs/FORGE.md documentait le risque au niveau de l'exécuteur seul, qui en a besoin pour créer les conteneurs. Les tâches, elles, n'en ont pas besoin.

Critères d'acceptation

container.valid_volumes de la configuration de l'exécuteur ne contient pas la socket Docker.
Un workflow d'essai qui tente d'y accéder échoue proprement.
L'exécuteur continue de créer ses conteneurs de tâche normalement, une exécution de la chaîne le prouve.
La configuration de l'exécuteur est versionnée, elle ne vit aujourd'hui que sur le serveur.
docs/FORGE.md corrige la portée du risque : il concernait les tâches, pas seulement l'exécuteur.

Comment on le vérifie

Commande un workflow d'essai avec « docker version » dans une tâche
Attendu échec sur socket absente, et la chaîne d'intégration toujours verte par ailleurs
Preuve les deux journaux d'exécution

Manuel d'exploitation à mettre à jour

docs/FORGE.md, section sur le risque assumé du socket

Risque et retour arrière

Retirer la socket peut casser une tâche qui en dépendrait sans qu'on le sache. Aucune n'en dépend aujourd'hui, la chaîne ne construit aucune image. À vérifier avant de l'appliquer, et le retour arrière tient en une ligne de configuration.

### Exigence couverte ENF-14, ENF-11 ### Épreuve servie EC03 · CI/CD et qualité ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Retirer la socket Docker des conteneurs de tâche de la chaîne d'intégration. Elle y est montée d'office par la configuration de l'exécuteur, et non déclarée par les workflows : **n'importe quelle poussée sur n'importe quelle branche dispose donc d'un accès root sur le serveur**, sans rien avoir à demander. C'est ce qui a permis de rétablir l'accès ce matin, et c'est précisément pour ça que c'est un problème. `docs/FORGE.md` documentait le risque au niveau de l'exécuteur seul, qui en a besoin pour créer les conteneurs. Les tâches, elles, n'en ont pas besoin. ### Critères d'acceptation - [ ] `container.valid_volumes` de la configuration de l'exécuteur ne contient pas la socket Docker. - [ ] Un workflow d'essai qui tente d'y accéder échoue proprement. - [ ] L'exécuteur continue de créer ses conteneurs de tâche normalement, une exécution de la chaîne le prouve. - [ ] La configuration de l'exécuteur est versionnée, elle ne vit aujourd'hui que sur le serveur. - [ ] `docs/FORGE.md` corrige la portée du risque : il concernait les tâches, pas seulement l'exécuteur. ### Comment on le vérifie Commande un workflow d'essai avec « docker version » dans une tâche Attendu échec sur socket absente, et la chaîne d'intégration toujours verte par ailleurs Preuve les deux journaux d'exécution ### Manuel d'exploitation à mettre à jour `docs/FORGE.md`, section sur le risque assumé du socket ### Risque et retour arrière Retirer la socket peut casser une tâche qui en dépendrait sans qu'on le sache. Aucune n'en dépend aujourd'hui, la chaîne ne construit aucune image. À vérifier avant de l'appliquer, et le retour arrière tient en une ligne de configuration.

lenaic added the

labels

2026-09-03 07:58:45 +00:00

lenaic self-assigned this

2026-09-03 07:58:45 +00:00