Restreindre les sorties réseau des runners CI/CD sans casser les déploiements

Pourquoi restreindre les sorties réseau d’un runner CI/CD

Un runner exécute du code qui change souvent : branches de pull request, dépendances, scripts de build et outils d’automatisation. Si ce code est compromis, la machine peut tenter d’exfiltrer des secrets ou de contacter une infrastructure hostile.

Le contrôle des flux sortants complète les permissions GitHub Actions, les credentials courts et l’isolation des runners. Il ne remplace aucune de ces protections : il limite surtout ce qu’un job peut faire après avoir obtenu une exécution.

Le modèle d’accès : observer, allowlister, contrôler

Commence par un périmètre de confiance : runners dédiés aux branches protégées, jobs de déploiement séparés des jobs de pull request et secrets injectés uniquement au dernier moment. Un runner qui compile du code non approuvé ne devrait pas partager le même accès réseau qu’un runner de production.

Inventorier les flux avant d’ajouter des règles

Les dépendances réseau sont rarement toutes documentées. Un build peut contacter le registre de conteneurs, le dépôt de paquets, une autorité de certificats, un fournisseur cloud ou un service de scan. Une allowlist écrite sans observation casse souvent une étape légitime.

# Exemple d’observation locale sur un runner Linux
sudo ss -tpn
sudo journalctl -u docker --since "15 minutes ago"
sudo tcpdump -ni any 'tcp and (port 80 or port 443)' -c 100
getent hosts registry.example.com

Dans un environnement réel, préfère les logs d’un proxy ou d’un firewall centralisé. Enregistre au minimum l’identité du runner, le workflow, la destination, le port, l’action autorisée ou bloquée et une durée de rétention adaptée à l’investigation.

Mini-lab : tester une allowlist sans risque

Le test ci-dessous utilise un conteneur jetable. Il ne modifie pas un runner de production et sert à valider le principe : une destination connue passe, une destination non déclarée est bloquée ou journalisée.

docker network create --internal ci-egress-lab
docker run --rm --network ci-egress-lab alpine:3.20 sh -c \
  'apk add --no-cache curl && curl -I --max-time 5 https://registry.example.com'

# Résultat attendu : la résolution ou la connexion échoue tant qu’aucune
# passerelle egress de test n’autorise explicitement la destination.
docker network rm ci-egress-lab

Sur un runner réellement utilisé, remplace l’expérimentation par un mode observation. Mesure le taux de jobs réussis, les destinations bloquées, la durée du build et les exceptions demandées. Le rollback consiste à désactiver la politique d’enforcement, pas à supprimer les logs ni les règles versionnées.

Déployer progressivement sans casser les déploiements

La première étape de production est une politique en mode audit. Elle produit des événements mais ne bloque rien. Après quelques cycles représentatifs, classe les destinations : indispensables, temporaires, liées à un outil à remplacer ou suspectes.

Ensuite, applique l’enforcement sur un seul groupe de runners. Les workflows de déploiement doivent rester séparés des workflows de contribution. Une exception temporaire doit avoir un propriétaire, une justification, une date d’expiration et une alerte si elle est encore active.

Checklist de mise en œuvre

Erreurs courantes

Faire vivre l’allowlist dans le temps

Une politique egress dérive dès que les équipes ajoutent un nouvel outil de build, changent de registre ou migrent un fournisseur cloud. L’allowlist doit donc être gérée comme un composant de la chaîne de livraison, avec une revue régulière et un historique compréhensible.

Chaque entrée devrait répondre à quatre questions : quel workflow l’utilise, quelle opération nécessite cette destination, qui en est responsable et quand la règle sera réévaluée ? Cette discipline évite les domaines orphelins qui restent autorisés après la suppression d’un outil.

Dans une PME SaaS, un fichier versionné peut suffire au départ. Le dépôt contient les règles par environnement, les exceptions temporaires et le résultat des tests. Une modification passe par une pull request distincte, relue par une personne qui connaît à la fois le réseau et le pipeline.

# Exemple de contrat d’allowlist lisible
environment: staging
runner_group: trusted-deploy
destinations:
  - host: registry.example.com
    ports: [443]
    reason: pull des images applicatives
    owner: equipe-platform
    expires: 2026-12-31
  - host: api.cloud.example
    ports: [443]
    reason: déploiement Terraform
    owner: equipe-infra
    expires: 2026-12-31

Le champ d’expiration est essentiel. Une exception sans date ressemble rapidement à une règle permanente, même si elle avait été créée pour dépanner une seule release. Une alerte hebdomadaire sur les expirations permet de traiter le sujet pendant les heures ouvrées.

Mesurer la sécurité sans dégrader la livraison

Le succès ne se mesure pas uniquement au nombre de connexions bloquées. Une politique trop stricte peut provoquer des contournements, des désactivations manuelles ou des délais de livraison qui poussent les équipes à chercher une solution moins sûre.

Surveille plutôt quelques indicateurs simples : taux de jobs réussis, temps médian du build, nombre d’exceptions actives, destinations inconnues par semaine et délai de traitement d’une demande d’accès. Compare ces mesures avant et après l’enforcement sur le même groupe de workflows.

Un blocage doit produire un événement actionnable. Le message doit identifier le dépôt, le workflow, le runner, la destination et la règle manquante. « Connexion refusée » ne suffit pas : l’équipe doit pouvoir décider rapidement si elle corrige le job, ajoute une destination justifiée ou traite une tentative suspecte.

Enfin, documente le chemin d’exception avant le jour où il sera nécessaire. Le demandeur fournit le workflow concerné, la destination exacte, la durée prévue et le résultat attendu. L’équipe plateforme peut alors accorder une règle limitée, vérifier son usage dans les logs, puis la retirer. Ce mécanisme protège la continuité métier tout en empêchant le dépannage de devenir une ouverture durable. Il faut également tester la procédure avec une personne qui n’a pas écrit la règle : si elle ne comprend pas le blocage, l’alerte et le retour arrière, le runbook est trop implicite. Cette relecture révèle souvent les dépendances oubliées et les responsabilités ambiguës.

Conclusion

La restriction des sorties réseau des runners CI/CD devient efficace quand elle est traitée comme une capacité d’exploitation : inventaire, règles versionnées, séparation des niveaux de confiance, alertes et rollback. Cette approche protège les déploiements sans transformer chaque incident de build en arrêt de livraison.

FAQ