Proxies pour les pipelines CI/CD : configuration de GitHub Actions, GitLab CI et Jenkins pour accéder aux ressources privées

Votre pipeline échoue avec l'erreur 403 Forbidden ou Connection refused lors de la tentative d'accès à une API externe ou de téléchargement d'une dépendance ? Il est probable que le problème soit que l'adresse IP de votre serveur CI/CD est bloquée du côté de la ressource. Un proxy résout ce problème : vous redirigez le trafic via l'IP souhaitée et le pipeline fonctionne sans interruption. Dans cet article, vous trouverez des instructions étape par étape pour GitHub Actions, GitLab CI et Jenkins.

Pourquoi un proxy dans CI/CD : scénarios réels

Les pipelines CI/CD fonctionnent sur des serveurs avec des adresses IP fixes — des runners cloud GitHub, GitLab ou sur des agents Jenkins auto-hébergés. Ces IP sont bien connues, et de nombreux services externes les bloquent ou limitent le nombre de requêtes. Voici des situations concrètes où un proxy est indispensable :

Accès aux ressources géo-restreintes

De nombreux registres npm d'entreprise, dépôts Maven et API internes ne sont accessibles que depuis certains pays ou plages d'IP. Si votre runner GitHub Actions se trouve dans une région qui est bloquée au niveau du pare-feu du service cible, le pipeline ne pourra pas télécharger les dépendances ou envoyer des données. Un proxy avec la géolocalisation appropriée résout ce problème sans modifier l'infrastructure.

Limitation de taux et blocages par IP

Les runners cloud GitHub Actions utilisent des IP des plages de Microsoft Azure. De nombreuses API publiques connaissent ces plages et leur appliquent des limites strictes — ou les bloquent complètement. Par exemple, le parsing de données publiques, les requêtes vers des API tierces pendant les tests, le téléchargement de distributions depuis des CDN restreints — tout cela échoue régulièrement à cause des IP des runners cloud. La rotation via un proxy permet de contourner la limitation de taux.

Tests d'intégration avec des sites réels

Si vos tests d'intégration accèdent à de vrais sites web ou marketplaces (Wildberries, Ozon, Avito, Amazon), ces sites voient la même IP du runner à chaque exécution et la bloquent rapidement. Un proxy avec rotation d'IP permet aux tests de passer de manière stable sans CAPTCHA ni blocages.

Accès aux ressources internes de l'entreprise

Les réseaux d'entreprise sont souvent fermés au monde extérieur. Si le pipeline doit déployer sur un serveur interne ou accéder à une API fermée, un proxy (ou tunnel SOCKS5) à l'intérieur du réseau d'entreprise devient un pont entre le runner cloud et l'infrastructure fermée.

Tests d'intégration publicitaires et marketing

Les équipes travaillant avec l'API Facebook Ads, l'API TikTok Ads ou l'API Google Ads automatisent souvent la création de campagnes via CI/CD. Ces plateformes ont des règles strictes concernant les IP : les requêtes provenant des IP des centres de données peuvent être bloquées ou nécessiter une vérification supplémentaire. Les proxies résidentiels dans le pipeline rendent les requêtes similaires à un trafic utilisateur normal.

Quel type de proxy choisir pour le pipeline

Le choix du type de proxy dépend de la tâche. Pour les pipelines CI/CD, trois options sont pertinentes — chacune avec ses avantages et ses limitations :

Configuration du proxy dans GitHub Actions

GitHub Actions est l'outil CI/CD le plus populaire aujourd'hui. La configuration du proxy ici se fait via des variables d'environnement et des secrets de dépôt. Détaillons étape par étape.

Étape 1 : Ajoutez les données du proxy dans les secrets du dépôt

Ne jamais inscrire le nom d'utilisateur et le mot de passe du proxy directement dans le fichier YAML du workflow. Utilisez les Secrets de GitHub :

1. Ouvrez le dépôt → Settings → Secrets and variables → Actions
2. Cliquez sur New repository secret
3. Créez un secret PROXY_URL avec une valeur du type http://user:[email protected]:port

Étape 2 : Utilisez les variables d'environnement dans le workflow

La plupart des outils (curl, wget, npm, pip, Maven) récupèrent automatiquement les variables d'environnement standard HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Exemple de workflow :

name: Build with Proxy

on: [push]

env:
  HTTP_PROXY: ${{ secrets.PROXY_URL }}
  HTTPS_PROXY: ${{ secrets.PROXY_URL }}
  NO_PROXY: localhost,127.0.0.1,internal.company.com

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Run integration tests
        run: npm test

      - name: Call external API
        run: |
          curl -v https://api.example.com/data

Étape 3 : Proxy SOCKS5 dans GitHub Actions

Si vous utilisez SOCKS5 (recommandé pour la plupart des tâches), les variables d'environnement standard ne suffisent pas — un tunnel local est nécessaire. Utilisez l'outil proxychains ou configurez microsocks :

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup SOCKS5 proxy tunnel
        run: |
          sudo apt-get install -y proxychains4
          echo "socks5 proxy.host 1080 user password" >> /etc/proxychains4.conf

      - name: Run command through SOCKS5
        run: proxychains4 curl https://restricted-resource.com/api

Configuration du proxy pour des outils spécifiques

Certains outils ignorent les variables système et nécessitent une configuration distincte :

Configuration du proxy dans GitLab CI

GitLab CI offre plusieurs niveaux pour définir des variables d'environnement : au niveau du projet, du groupe ou de l'instance. Cela rend la gestion des proxies plus flexible par rapport à GitHub Actions.

Étape 1 : Ajoutez des variables dans GitLab CI/CD Variables

1. Ouvrez le projet → Settings → CI/CD → section Variables
2. Cliquez sur Add variable
3. Ajoutez la variable PROXY_URL avec le type Masked (cache la valeur dans les logs)
4. Valeur : http://user:[email protected]:port

Étape 2 : Utilisez les variables dans .gitlab-ci.yml

variables:
  HTTP_PROXY: $PROXY_URL
  HTTPS_PROXY: $PROXY_URL
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build

integration_tests:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest tests/integration/

deploy:
  stage: deploy
  script:
    - curl -X POST https://api.external-service.com/deploy
      -H "Authorization: Bearer $DEPLOY_TOKEN"
      -d '{"version": "$CI_COMMIT_SHA"}'

Proxy uniquement pour des jobs spécifiques

Si le proxy n'est pas nécessaire partout (par exemple, uniquement pour les tests d'intégration, mais pas pour la construction), définissez les variables au niveau d'un job spécifique, et non globalement :

integration_tests:
  stage: test
  variables:
    HTTP_PROXY: $PROXY_URL
    HTTPS_PROXY: $PROXY_URL
  script:
    - pytest tests/integration/

build:
  stage: build
  # Ici, le proxy n'est pas défini — connexion directe
  script:
    - npm ci && npm run build

GitLab Runner auto-hébergé : configuration du proxy au niveau du runner

Si vous utilisez votre propre GitLab Runner, vous pouvez définir le proxy globalement dans la configuration du runner. Ouvrez le fichier /etc/gitlab-runner/config.toml et ajoutez dans la section [runners.env] :

[[runners]]
  name = "my-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "docker"
  environment = [
    "HTTP_PROXY=http://user:[email protected]:port",
    "HTTPS_PROXY=http://user:[email protected]:port",
    "NO_PROXY=localhost,127.0.0.1"
  ]

C'est pratique lorsque tous les pipelines sur ce runner doivent utiliser le proxy — il n'est pas nécessaire de le spécifier dans chaque .gitlab-ci.yml.

Configuration du proxy dans Jenkins

Jenkins est l'outil le plus flexible des trois, mais aussi le plus complexe à configurer. Le proxy peut être défini à plusieurs niveaux : globalement pour tout Jenkins, pour un Pipeline spécifique ou pour une étape individuelle.

Méthode 1 : Paramètres globaux du proxy dans Jenkins

1. Ouvrez Manage Jenkins → System
2. Trouvez la section HTTP Proxy Configuration
3. Remplissez les champs : Serveur, Port, Nom d'utilisateur, Mot de passe
4. Dans le champ No Proxy Host, indiquez les adresses internes séparées par des virgules
5. Cliquez sur Test URL pour vérifier et enregistrez

Ce paramètre affecte le téléchargement des plugins et des mises à jour de Jenkins lui-même, mais n'est pas automatiquement transmis à l'environnement d'exécution des pipelines. Une configuration distincte est nécessaire pour les pipelines.

Méthode 2 : Proxy dans un Pipeline déclaratif via environment

pipeline {
    agent any

    environment {
        HTTP_PROXY  = credentials('proxy-url-credential')
        HTTPS_PROXY = credentials('proxy-url-credential')
        NO_PROXY    = 'localhost,127.0.0.1,internal.company.com'
    }

    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }

        stage('Integration Tests') {
            steps {
                sh 'pytest tests/integration/'
            }
        }

        stage('Deploy') {
            steps {
                sh '''
                    curl -X POST https://api.external-service.com/deploy \
                    -H "Authorization: Bearer ${DEPLOY_TOKEN}" \
                    -d "version=${GIT_COMMIT}"
                '''
            }
        }
    }
}

Étape 3 : Ajoutez les identifiants du proxy dans les Credentials de Jenkins

1. Ouvrez Manage Jenkins → Credentials → System → Global credentials
2. Cliquez sur Add Credentials
3. Type : Secret text
4. ID : proxy-url-credential
5. Secret : http://user:[email protected]:port

Méthode 3 : Proxy via les paramètres JVM pour les projets Java

Si votre pipeline construit un projet Java (Maven, Gradle), les variables d'environnement système peuvent ne pas fonctionner — la JVM utilise ses propres propriétés système. Ajoutez-les dans JAVA_OPTS :

environment {
    JAVA_OPTS = '-Dhttps.proxyHost=proxy.host -Dhttps.proxyPort=8080 -Dhttps.proxyUser=user -Dhttps.proxyPassword=password -Dhttp.nonProxyHosts=localhost|127.0.0.1|*.internal.com'
}

Proxy à l'intérieur des conteneurs Docker dans le pipeline

La plupart des pipelines CI/CD modernes exécutent des étapes à l'intérieur de conteneurs Docker. La transmission du proxy dans le conteneur est une tâche distincte qui peut être résolue de plusieurs manières.

Transmission du proxy via --build-arg lors de la construction de l'image

Si le proxy est nécessaire uniquement lors de la construction de l'image Docker (par exemple, pour l'installation de paquets à l'intérieur du Dockerfile), utilisez des arguments de construction :

# Dans .github/workflows/build.yml ou .gitlab-ci.yml
docker build \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --build-arg HTTPS_PROXY=$HTTPS_PROXY \
  --build-arg NO_PROXY=$NO_PROXY \
  -t myapp:latest .

# Dans Dockerfile
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

RUN apt-get update && apt-get install -y curl
RUN npm ci

Configuration globale du démon Docker pour le proxy

Sur des runners auto-hébergés, vous pouvez configurer le proxy pour tout le démon Docker — alors tous les conteneurs recevront automatiquement le proxy sans modifications dans le Dockerfile :

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://user:[email protected]:port"
Environment="HTTPS_PROXY=http://user:[email protected]:port"
Environment="NO_PROXY=localhost,127.0.0.1,registry.internal.com"

# Appliquer les modifications :
# systemctl daemon-reload
# systemctl restart docker

Sécurité : comment stocker les identifiants du proxy

Les identifiants du proxy sont des secrets tout aussi importants que les clés API ou les mots de passe des bases de données. Leur fuite signifie que quiconque pourra utiliser votre proxy à vos dépens. Voici les règles de stockage sécurisé :

Checklist de sécurité

• ✅ Jamais n'inscrivez le nom d'utilisateur/mot de passe du proxy directement dans les fichiers YAML du pipeline
• ✅ Utilisez des variables masquées dans GitLab et des secrets chiffrés dans GitHub — elles sont cachées dans les logs
• ✅ Dans Jenkins, utilisez le type Secret text ou Username with password dans le Credentials Store
• ✅ Ajoutez NO_PROXY pour les adresses internes — le trafic vers votre infrastructure ne doit pas passer par le proxy
• ✅ Faites régulièrement tourner les mots de passe du proxy — mettez-les à jour uniquement dans le stockage des secrets, sans changer le code du pipeline
• ✅ Utilisez l'authentification IP du proxy (whitelist IP du runner) là où cela est pris en charge — c'est plus fiable qu'un mot de passe
• ✅ Vérifiez les logs du proxy pour détecter une activité inhabituelle

Format de l'URL du proxy : quoi insérer où

Erreurs fréquentes et comment les corriger

Même après une configuration correcte, des problèmes peuvent survenir. Voici les erreurs les plus courantes et leurs solutions :

Erreur : Proxy Authentication Required (407)

Erreur : SSL Certificate Verification Failed

Erreur : Connection Timeout via le proxy

Erreur : L'outil ignore les variables HTTP_PROXY

Erreur : Les services internes passent aussi par le proxy

Conclusion

La configuration du proxy dans un pipeline CI/CD n'est pas une tâche ponctuelle, mais fait partie d'une architecture d'automatisation correcte. Nous avons examiné trois outils principaux : GitHub Actions (via Secrets et variables d'environnement), GitLab CI (via Variables avec masquage) et Jenkins (via Credentials Store et Pipeline déclaratif). Les principes clés sont les mêmes pour tous : ne jamais stocker les identifiants dans le code, utiliser NO_PROXY pour les adresses internes et choisir le type de proxy en fonction de la tâche spécifique.

Le choix du bon type de proxy est crucial pour la stabilité du pipeline. Pour le téléchargement de dépendances et les appels aux API standards, des proxies de centre de données rapides suffisent. Si votre pipeline effectue des tests d'intégration sur des sites réels, travaille avec des plateformes publicitaires (API Facebook Ads, API TikTok Ads) ou accède à des marketplaces — utilisez des proxies résidentiels : leurs IP sont perçues comme un trafic utilisateur normal et sont très rarement soumises à des blocages ou à des limitations de taux.

La règle principale : testez le proxy dans une étape distincte au début du pipeline — cela permettra de diagnostiquer rapidement les problèmes et de ne pas perdre de temps à chercher une erreur à la fin d'une longue construction. Ajoutez une étape curl -v https://api.ipify.org immédiatement après la configuration du proxy — cela montrera l'IP à partir de laquelle les requêtes partent et confirmera que le proxy fonctionne correctement.