Aller au contenu

📝 RETOUR D'EXPÉRIENCE — PD-12

📚 Navigation User Story | Document | | | ---------- | -- | | 📋 SpĂ©cification | [PD-12-specification.md](PD-12-specification.md) | | đŸ› ïž Plan d'implĂ©mentation | [PD-12-plan.md](PD-12-plan.md) | | ✅ CritĂšres d'acceptation | [PD-12-acceptability.md](PD-12-acceptability.md) | | 📝 **Retour d'expĂ©rience** | *(ce document)* | [← Retour Ă  infrastructure-souveraine](../PD-193-epic.md) · [↑ Index User Story](index.md)

PD-12 — Configuration GitLab Runner pour CI/CD

1. Résumé exécutif

L'objectif était de mettre en place des GitLab Runners sécurisés avec executors Docker, gestion du cache et des secrets, sur infrastructure OVH.

L'implémentation a livré 3 runners sur 2 VPS : un runner Docker privilégié pour les builds HSM, un runner Shell pour l'infra (Terraform/Ansible), et un runner Docker isolé sur VPS dédié pour les jobs publics.

Verdict : Accepté avec réserves. La spécification prévoyait uniquement des executors Docker isolés, mais les contraintes opérationnelles (accÚs VPN CloudHSM, opérations SSH/Terraform) ont nécessité des déviations documentées. Un écart de sécurité (token exposé dans les logs) a été corrigé en cours de revue.

2. Points fluides

  • DĂ©ploiement Ansible reproductible : Les playbooks setup_gitlab_complete.yml et setup_internet_runner.yml permettent un dĂ©ploiement idempotent et versionnĂ©.
  • SĂ©paration des runners par niveau de confiance : Architecture tri-runner (docker/shell/internet) claire et documentĂ©e.
  • IntĂ©gration HashiCorp Vault : Les credentials VPS et tokens GitLab sont centralisĂ©s dans Vault.
  • Templates Jinja2 configurables : Les fichiers config.toml.j2 permettent de paramĂ©trer chaque runner sans duplication.
  • Documentation opĂ©rationnelle : Le fichier internet-runner.md documente clairement l'architecture et les procĂ©dures de maintenance.
  • Pre-pull des images Docker : Évite les timeouts DNS au premier run.

3. Points difficiles

Obstacle Contexte
AccÚs VPN CloudHSM depuis Docker Les conteneurs en mode bridge ne peuvent pas atteindre le tunnel IPsec (10.0.1.x). Solution : network_mode = host pour le runner principal, ce qui réduit l'isolation.
Opérations infra non-Dockerisables Terraform et Ansible nécessitent un accÚs SSH direct et un état local. Un executor Shell a été ajouté, hors périmÚtre initial de la spec.
RĂ©solution DNS OVH Le DNS systemd-resolved sur Ubuntu 24.04 causait des timeouts. Solution : forcer les DNS publics (8.8.8.8, 1.1.1.1) dans la config Docker.
Isolation du runner internet La création d'un VPS dédié n'était pas prévue initialement. Elle a été décidée pour garantir une vraie isolation réseau (pas d'accÚs VPN/interne).
Token GitLab exposé dans les logs Découvert en revue d'acceptabilité. Corrigé par stockage dans HashiCorp Vault avec no_log: true.

4. HypothÚses révélées tardivement

HypothÚse implicite Réalité découverte
Tous les jobs peuvent tourner dans Docker isolé Les jobs HSM nécessitent un accÚs réseau VPN depuis l'hÎte
Un seul VPS suffit pour tous les runners L'isolation réseau réelle nécessite un VPS séparé
L'API GitLab Session fonctionne pour créer des PAT L'API /api/v4/session est deprecated, mais fonctionne encore
80GB de cache suffisent Non validé en production, à surveiller

5. Invariants complexes

Invariant Difficulté
INV-2 : Isolation des jobs Impossible à garantir à 100% pour le runner principal (mode host + privileged). L'isolation est assurée uniquement sur le runner internet (bridge + non-privileged).
INV-3 : Pas d'accÚs croisé entre jobs Le montage de docker.sock permet techniquement à un job d'inspecter/tuer d'autres conteneurs. Mitigation : séparation par tags et confiance dans les pipelines internes.
INV-1 : Pas de secrets en clair NĂ©cessite une vigilance constante. Le playbook Ansible a dĂ» ĂȘtre corrigĂ© aprĂšs revue. Les variables GitLab CI/CD doivent ĂȘtre marquĂ©es masked.

6. Dette technique

Dette Impact Priorité
Spec incomplĂšte sur les executors La spĂ©cification ne prĂ©voit que Docker, mais Shell est nĂ©cessaire pour l'infra. La spec devrait ĂȘtre amendĂ©e pour formaliser ce cas. Faible
Pas de nettoyage automatique du cache Le cache Docker et CI peut remplir le disque. Un cron docker system prune est recommandé mais non déployé. Moyenne
Tokens runner dans Ansible Vault Duplication avec HashiCorp Vault. À terme, tout centraliser dans HashiCorp Vault. Faible
Pas de monitoring des runners Aucune alerte si un runner passe offline. Supervision manuelle via GitLab UI. Moyenne

7. Risques résiduels

Risque Probabilité Impact Mitigation actuelle
Escalade de privilÚges via docker.sock Faible Critique Seuls les pipelines internes (Maintainer+) peuvent exécuter sur ovh-docker
Compromission du VPS principal Faible Critique AccÚs SSH limité, firewall OVH, VPN CloudHSM
Token runner volé Faible Majeur run_untagged = false, révocation possible via GitLab UI
Remplissage disque cache Moyenne Majeur Monitoring manuel, pas de cron automatique
Timeout DNS au pull d'images Faible Mineur Pre-pull des images critiques, DNS publics forcés

8. Améliorations processus

Suggestion Bénéfice attendu
Inclure les contraintes infra dans la spec Éviter les Ă©carts entre spec "pure Docker" et rĂ©alitĂ© opĂ©rationnelle (Shell, VPN, etc.)
Revue sécurité systématique des playbooks Ansible Détecter les expositions de secrets avant acceptabilité
Documenter les trade-offs architecturaux en ADR Formaliser les décisions comme "mode host pour VPN" plutÎt que les découvrir en revue
Ajouter des tests d'isolation Valider que deux jobs parallĂšles ne peuvent pas interagir
Automatiser le monitoring des runners Alertes Slack/email si runner offline > 5 min

9. Enseignements clés

  1. Les specs théoriques rencontrent les contraintes opérationnelles : L'exigence "Docker isolé partout" n'est pas tenable quand on doit accéder à un VPN IPsec ou exécuter du Terraform avec état local.

  2. L'isolation réseau réelle nécessite une séparation physique : Un VPS dédié pour le runner internet a été la seule solution pour garantir l'absence d'accÚs aux services internes.

  3. Les secrets fuient facilement dans les logs Ansible : Une tùche debug innocente a exposé un token GitLab. La revue d'acceptabilité a permis de le détecter et le corriger.

  4. L'architecture tri-runner est un bon compromis : Séparer les runners par niveau de confiance (privileged/shell/isolated) permet d'adapter la sécurité au contexte de chaque job.

  5. La documentation opérationnelle est indispensable : Le fichier internet-runner.md a permis de transférer la connaissance de l'architecture multi-VPS.

Fin du retour d'expérience PD-12.