Stockage et transmission des identifiants proxy dans les pipelines CI/CD sans fuite : guide pas à pas

Les identifiants proxy se retrouvent dans les journaux de build publics plus souvent qu'on ne le pense. Un simple curl -v imprudent, une variable en clair, un mot de passe dans une URL — et votre identifiant avec votre mot de passe se retrouvent dans l'historique du pipeline, accessible à toute l'équipe. Dans ce guide, nous allons voir comment éviter cela.

Introduction : comment les identifiants proxy fuient dans les journaux et l'historique

Imaginez une situation typique. Vous configurez un build qui passe par le proxy Proxeon pour accéder à des ressources externes. Pour vérifier rapidement la connexion, vous écrivez une commande avec le mot de passe directement dans l'adresse : http://user:pass@host:port. Le build réussit, vous êtes content. Une semaine plus tard, vous découvrez que le mot de passe est visible dans le journal de chaque exécution, dans l'historique du shell sur le runner et même dans la sortie de débogage du client.

Ce n'est pas rare, c'est une tendance. Les identifiants proxy ont cette fâcheuse propriété : ils sont nécessaires dans presque chaque appel réseau, donc ils s'infiltrent facilement dans des dizaines d'endroits à la fois.

Ce que vous obtiendrez à la fin

Après avoir suivi ce guide, vous pourrez configurer votre CI/CD de sorte que les identifiants proxy n'apparaissent ni dans les journaux, ni dans l'historique des commandes, ni dans le dépôt. Vous apprendrez à utiliser les secrets des systèmes populaires, à désactiver les modes de débogage dangereux, à changer le mot de passe en toute sécurité sans arrêter les builds et à tout vérifier avec un script prêt à l'emploi.

Pour qui est ce guide

Ce matériel s'adresse aux ingénieurs de niveau intermédiaire : DevOps, développeurs back-end, automatiseurs QA. Si vous savez déjà lancer un pipeline et que vous savez ce qu'est une variable d'environnement, vous serez à l'aise. Les lecteurs avancés trouveront des sections sur la rotation et l'audit.

Ce qu'il faut savoir à l'avance

Nous ne reviendrons pas sur la configuration de base des variables http_proxy et no_proxy — un autre article y est consacré. On suppose que la connexion au proxy fonctionne déjà, et que la tâche est maintenant de sécuriser le stockage des identifiants.

Temps nécessaire

La lecture et la compréhension prendront environ 40 minutes. Pour l'implémentation dans un pipeline, comptez de 30 minutes à une heure et demie selon le système CI. La rotation et la vérification des fuites s'ajouteront plus tard, elles prennent chacune 15 à 20 minutes.

Préparation préalable : ce qu'il vous faut

Avant de commencer, rassemblez tout le nécessaire. Cela vous fera gagner du temps et évitera les interruptions en cours de travail.

Outils et accès

• Accès à votre projet CI/CD avec les droits de modifier les paramètres et les secrets.
• Abonnement proxy Proxeon actif avec identifiant, mot de passe, hôte et port.
• Machine locale avec curl, git, ainsi que les interpréteurs Python 3 et Node.js si vous prévoyez d'utiliser les exemples.
• Éditeur de texte pour modifier les fichiers de configuration du pipeline.

Exigences système

Aucune exigence particulière. Tout fonctionne sous Linux, macOS et Windows. Les runners CI sont généralement basés sur Linux, donc la plupart des exemples sont donnés en syntaxe bash. Pour les runners Windows, nous mentionnerons les différences séparément.

Ce qu'il faut préparer à l'avance

Notez vos identifiants proxy actuels dans un gestionnaire de mots de passe fiable. Ils vous serviront lors de la configuration des secrets. Ne les stockez pas dans un fichier texte ordinaire sur votre bureau.

Conseil : Créez un compte proxy séparé pour le CI, si votre formule Proxeon le permet. Ainsi, une compromission des identifiants de build n'affectera pas vos identifiants personnels et vice versa.

Sauvegarde de la configuration

Avant de modifier le pipeline, faites une copie du fichier de configuration actuel. Copiez simplement .gitlab-ci.yml, le fichier de workflow ou le Jenkinsfile dans un dossier séparé en dehors du dépôt.

⚠️ Attention : Ne sauvegardez jamais en commitant dans le même dépôt avec le mot de passe à l'intérieur. Même dans une branche temporaire, les identifiants entreront dans l'historique git pour toujours.

Concepts de base : termes simples

Décortiquons les mots-clés pour ne pas se tromper plus loin.

Identifiants proxy

Ce sont l'identifiant et le mot de passe que votre client utilise pour confirmer le droit d'utiliser le proxy Proxeon. Parfois, une liaison par IP est utilisée à la place de l'identifiant/mot de passe, mais ici nous parlons de la paire identifiant-mot de passe.

Secret dans le CI

Un secret est un stockage spécial dans le système CI, dans lequel vous placez une valeur sensible. Le système la chiffre et l'injecte dans le build comme variable d'environnement, tout en la masquant automatiquement dans les journaux.

Masquage

Le masquage est le processus par lequel le CI remplace la valeur du secret dans la sortie par des astérisques. Si le mot de passe est imprimé accidentellement, vous verrez quelque chose comme [MASKED] à la place. Cela ne fonctionne pas toujours parfaitement, nous allons donc combiner plusieurs protections.

En-tête Proxy-Authorization

Lorsque le client s'authentifie sur le proxy, il envoie l'en-tête HTTP Proxy-Authorization avec les identifiants encodés. En mode de débogage détaillé, de nombreux clients impriment cet en-tête en entier. Le décoder est trivial, donc cette sortie est considérée comme une fuite.

Portée

La portée détermine quels builds ont accès au secret. Un secret correctement limité n'est visible que par les branches protégées et ne tombe pas dans les forks ou les pull requests externes.

Conseil : Retenez le principe principal : le secret doit exister dans la mémoire du processus exactement le temps nécessaire et ne laisser aucune trace sur le disque ou dans la sortie.

Étape 1 : Comprendre le piège principal — le mot de passe dans l'URL

Objectif de cette étape : apprendre à reconnaître la source de fuite la plus fréquente et à y renoncer définitivement.

L'erreur la plus courante est de mettre les identifiants directement dans l'adresse du proxy : http://user:pass@host:port. C'est pratique, donc presque tous les débutants le font. Le problème est que cette URL apparaît dans des endroits inattendus.

Où exactement le mot de passe de l'URL apparaît

1. Liste des processus. La commande ps sur le runner affichera la ligne de commande complète, y compris le mot de passe. Tout processus sur la même machine peut la lire.
2. Journaux du proxy lui-même. Certains journaux serveur enregistrent la chaîne de connexion. Si l'URL contient le mot de passe, il se retrouve dans le journal.
3. Historique des commandes shell. Le fichier .bash_history garde tout ce que vous avez saisi, y compris le mot de passe dans l'URL.
4. Sortie de débogage du client. En mode verbeux, le client imprime l'adresse de destination avec les identifiants.
5. Journaux CI. Si la variable avec l'URL n'est pas marquée comme secret, elle est imprimée en clair lors d'un echo ou en cas d'erreur.

Vérifiez tout de suite. Exécutez une commande inoffensive sur une machine et regardez la liste des processus.

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

Vous verrez votre mot de passe en clair dans la sortie de ps. C'est exactement la fuite que nous voulons éliminer.

⚠️ Attention : Même si le build est privé, un autre processus, un autre job sur un runner partagé ou un outil de surveillance peut avoir accès à la liste des processus du runner. Considérez le mot de passe dans l'URL comme public.

Résultat attendu : vous comprenez les cinq endroits de fuite et vous ne mettrez plus jamais le mot de passe dans l'adresse du proxy.

✅ Vérification : exécutez la commande de test ci-dessus et assurez-vous de voir le mot de passe dans la sortie ps. Si vous le voyez, vous avez correctement reproduit le problème et êtes prêt à le résoudre.

Étape 2 : La bonne méthode — variables d'environnement et fichiers d'identifiants

Objectif de cette étape : déplacer les identifiants de l'URL vers des stockages sûrs — variables d'environnement et fichiers spéciaux.

L'idée est simple. L'identifiant et le mot de passe sont stockés séparément de l'adresse. Le client les lit depuis l'environnement ou depuis un fichier aux droits restreints, pas depuis la ligne de commande. Ainsi, ils n'apparaissent ni dans la liste des processus ni dans l'historique.

Option A : Variables d'environnement

De nombreux clients savent lire les identifiants proxy depuis l'environnement. Voyons des exemples.

curl via variable d'environnement

Définissez l'adresse du proxy sans identifiants, et passez l'identifiant et le mot de passe via un drapeau séparé, dont la valeur vient d'une variable.

1. Exportez la variable avec les identifiants dans l'environnement (dans le CI, ce sera un secret ; en local, une source sécurisée).
2. Passez sa valeur via le drapeau -U, pas dans l'URL.

export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

Même le drapeau -U avec une variable est mieux que le mot de passe dans l'URL, mais il est aussi visible dans ps. C'est pourquoi le fichier d'identifiants, décrit ci-dessous, est préférable.

Python requests

En Python, lisez les identifiants depuis l'environnement via os.environ et construisez le dictionnaire proxies en mémoire. N'imprimez rien.

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

Ici, le mot de passe reste dans une variable à l'intérieur du processus Python et n'apparaît pas dans la ligne de commande. Le principal est de ne pas journaliser la variable proxy en entier.

Node.js

Dans Node, prenez aussi les identifiants depuis process.env et créez l'agent proxy dans le code.

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

Conseil : Dans tout langage, ne journalisez que le statut de la réponse et, si nécessaire, l'hôte de destination. Ne jamais imprimer l'objet de configuration du proxy en entier — il contient le mot de passe.

Option B : Fichier .netrc

Le fichier .netrc est une méthode classique pour stocker les identifiants séparément des commandes. curl sait le lire automatiquement.

1. Créez le fichier .netrc dans le répertoire personnel du runner à la volée, à partir du secret CI.
2. Inscrivez une ligne avec la machine, l'identifiant et le mot de passe.
3. Définissez les permissions à 600 pour que seul le propriétaire puisse lire le fichier.
4. Lancez curl avec le drapeau d'utilisation de netrc.

printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Maintenant, le mot de passe n'apparaît ni dans la ligne de commande, ni dans la liste des processus. Il se trouve dans un fichier avec les droits 600, que vous supprimerez à la fin du build.

⚠️ Attention : Les droits 600 sont obligatoires. Sans eux, curl peut refuser de lire le fichier, et le fichier lui-même deviendra accessible aux autres utilisateurs de la machine.

Option C : Fichier de configuration curl

curl sait lire les drapeaux depuis un fichier de configuration. Mettez-y le proxy et les identifiants, puis définissez les droits 600.

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

Avec un .curlrc aux droits 600, les identifiants ne sont pas visibles dans le processus et ne sont pas écrits dans l'historique.

Option D : Configuration du client applicatif

Si vous avez votre propre application qui lit une configuration, stockez les identifiants proxy dans un fichier de configuration hors du dépôt. Dans le dépôt, ne gardez qu'un modèle avec des placeholders, et remplacez les valeurs réelles sur le runner à partir des secrets.

Résultat attendu : dans aucun exemple le mot de passe n'apparaît dans la ligne de commande ni dans la liste des processus. Il vit soit dans une variable à l'intérieur du processus, soit dans un fichier aux droits 600.

✅ Vérification : exécutez n'importe quel exemple et parallèlement, lancez ps aux | grep curl. Le mot de passe ne doit pas apparaître. Si vous utilisez netrc, vérifiez les droits avec ls -l ~/.netrc — cela doit être -rw-------.

Étape 3 : Secrets dans les CI populaires — GitHub Actions, GitLab CI, Jenkins

Objectif de cette étape : placer les identifiants proxy dans le stockage protégé de votre système CI et les injecter sans fuite.

GitHub Actions

Dans GitHub, les secrets sont stockés au niveau du dépôt ou de l'organisation.

1. Ouvrez le dépôt et allez dans la section des paramètres Settings.
2. À gauche, trouvez Secrets and variables, puis Actions.
3. Cliquez sur New repository secret.
4. Entrez un nom, par exemple PROXEON_USER, et la valeur — votre identifiant. Enregistrez.
5. Répétez pour PROXEON_PASS avec le mot de passe.

Dans le workflow, accédez aux secrets via le contexte secrets et passez-les à l'étape comme variables d'environnement.

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

GitHub masque automatiquement les valeurs des secrets dans les journaux. Si le mot de passe est imprimé accidentellement, vous verrez trois astérisques.

⚠️ Attention : Par défaut, les secrets ne sont pas disponibles dans les workflows déclenchés par des forks via pull_request. Ne changez pas ce comportement vers pull_request_target sans nécessité absolue — sinon un contributeur externe pourrait obtenir vos identifiants.

GitLab CI

Dans GitLab, les secrets sont appelés variables CI/CD et se configurent dans le projet.

1. Ouvrez le projet, allez dans Settings, puis CI/CD.
2. Dépliez la section Variables et cliquez sur Add variable.
3. Entrez la clé PROXEON_USER et la valeur.
4. Cochez Masked pour que la valeur soit masquée dans les journaux.
5. Cochez Protected pour que la variable ne soit accessible qu'aux branches et tags protégés.
6. Répétez pour PROXEON_PASS.

Dans .gitlab-ci.yml, les variables sont disponibles automatiquement comme environnement.

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Conseil : Le drapeau Masked dans GitLab ne fonctionne que pour les valeurs qui satisfont aux règles : longueur minimale, pas de retour à la ligne, jeu de caractères compatible base64. Si le mot de passe n'est pas masqué, GitLab affichera un avertissement lors de l'enregistrement. Dans ce cas, changez le mot de passe pour qu'il réponde aux exigences.

Jenkins

Dans Jenkins, les identifiants sont stockés dans la section Credentials et injectés via le plugin Credentials Binding.

1. Ouvrez Manage Jenkins, puis Credentials.
2. Choisissez la portée, par exemple System et Global credentials.
3. Cliquez sur Add Credentials.
4. Choisissez le type Username with password.
5. Entrez l'identifiant et le mot de passe du proxy, définissez un ID clair, par exemple proxeon-creds.

Dans le Jenkinsfile, enveloppez l'utilisation dans un bloc withCredentials. Jenkins masque les valeurs dans la console.

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ Attention : Jenkins ne masque que les valeurs définies via Credentials Binding. Si vous construisez le mot de passe avec une chaîne en Groovy et l'imprimez, le masquage ne fonctionnera pas. Travaillez avec les identifiants uniquement à l'intérieur du bloc withCredentials et uniquement dans les étapes sh.

Résultat attendu : les identifiants sont dans le stockage protégé de votre système CI, sont injectés dans le build comme environnement et sont masqués dans les journaux.

✅ Vérification : lancez un build et ouvrez le journal. Assurez-vous que des astérisques ou un marqueur de masquage apparaissent au lieu du mot de passe. Essayez d'afficher délibérément la variable avec echo — le système doit la masquer.

Étape 4 : Journaux — désactivation des modes qui impriment Proxy-Authorization

Objectif de cette étape : supprimer la sortie verbeuse là où elle révèle l'en-tête d'autorisation, et conserver un niveau de journalisation sûr.

Le masquage du CI n'est pas une panacée. Si le client imprime l'en-tête Proxy-Authorization en base64 et que le système ne connaît pas le mot de passe original en toutes lettres, le masquage peut ne pas fonctionner. Nous désactivons donc les modes dangereux à la source.

curl

Le drapeau -v et surtout --trace impriment les en-têtes, y compris l'autorisation du proxy. Dans le CI, utilisez le mode silencieux.

1. Retirez -v, --verbose, --trace et --trace-ascii des commandes de build.
2. Pour le contrôle des erreurs, utilisez -sS : silencieux, mais affiche les erreurs.
3. Si vous avez besoin de déboguer, utilisez --trace uniquement en local, jamais dans le CI.

curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

Ainsi, vous n'obtenez que le code de réponse sans aucun en-tête dans la sortie.

Python requests

La bibliothèque requests n'imprime pas les identifiants d'elle-même, mais si le niveau de journalisation urllib3 est réglé sur DEBUG, il affiche les en-têtes des requêtes. Gardez le niveau de journalisation sur WARNING ou INFO.

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

Conseil : Si vous avez vraiment besoin de DEBUG pour le diagnostic, ajoutez un filtre de journalisation qui supprime l'en-tête Proxy-Authorization des messages. Mais il est plus simple de diagnostiquer en local et de garder WARNING dans le CI.

Node.js

Dans Node, évitez de définir la variable NODE_DEBUG=http dans le CI — elle affiche les en-têtes. N'imprimez pas non plus l'objet agent ni l'objet requête en entier.

1. Retirez NODE_DEBUG de l'environnement du runner.
2. Dans les gestionnaires d'erreurs, n'imprimez que error.message, pas l'objet entier.
3. N'utilisez pas de bibliothèques de journalisation des requêtes HTTP dans un build de production.

⚠️ Attention : La stack trace d'une exception non gérée peut aussi contenir l'URL du proxy avec les identifiants si vous avez construit l'URL avec le mot de passe. C'est une raison de plus de ne pas mettre le mot de passe dans l'URL, mais d'utiliser netrc ou des champs séparés.

Résultat attendu : aucun outil dans le CI n'imprime l'en-tête d'autorisation ni l'URL complète du proxy.

✅ Vérification : exécutez le build et cherchez dans le journal les chaînes Proxy-Authorization, Basic et le nom de votre utilisateur. Aucune correspondance ne doit apparaître.

Étape 5 : Rotation du mot de passe proxy sans arrêt des builds

Objectif de cette étape : apprendre à changer le mot de passe sans faire échouer les builds et en veillant à ce que l'ancien mot de passe cesse de fonctionner.

Le mot de passe proxy doit être changé périodiquement et impérativement après toute suspicion de fuite. La tâche est de le faire sans fenêtre d'indisponibilité.

Stratégie de chevauchement

La solution idéale est que, pendant un certain temps, l'ancien et le nouveau mot de passe soient valables. Si votre formule Proxeon permet de créer un deuxième compte ou un ensemble supplémentaire d'identifiants, utilisez cela.

1. Créez de nouveaux identifiants proxy dans votre espace client Proxeon, sans supprimer les anciens.
2. Ajoutez les nouvelles valeurs dans les secrets CI sous des noms temporaires, par exemple PROXEON_USER_NEW.
3. Basculez le pipeline sur les nouveaux noms dans une branche séparée et exécutez un build.
4. Assurez-vous que le build passe avec les nouveaux identifiants.
5. Remplacez les valeurs des secrets principaux PROXEON_USER et PROXEON_PASS par les nouvelles.
6. Supprimez les secrets temporaires.
7. Révoquez les anciens identifiants dans l'espace client Proxeon.

Ainsi, à chaque instant, il existe un ensemble d'identifiants fonctionnel, et les builds ne tombent pas.

Si le chevauchement n'est pas disponible

Lorsqu'une seule paire d'identifiants est disponible, agissez pendant une fenêtre calme.

1. Choisissez un moment avec une activité minimale des builds.
2. Mettez en pause le lancement de nouveaux pipelines pendant quelques minutes.
3. Changez le mot de passe dans l'espace client Proxeon.
4. Mettez immédiatement à jour la valeur du secret dans le CI.
5. Lancez un build de vérification.
6. Reprenez le travail normal.

Conseil : Établissez une procédure de rotation courte et gardez-la près de la description du pipeline. En situation de stress après une fuite, une liste d'étapes prête à l'emploi économise les nerfs et le temps.

⚠️ Attention : Après avoir changé le mot de passe, supprimez l'ancien fichier netrc ou curlrc du runner s'il est mis en cache entre les builds. Sinon, le client continuera d'utiliser les anciens identifiants.

Résultat attendu : le mot de passe est changé, les nouveaux builds utilisent les nouveaux identifiants, l'ancien mot de passe ne fonctionne plus.

✅ Vérification : essayez d'effectuer une requête avec l'ancien mot de passe — vous devriez obtenir une erreur d'autorisation du proxy. Pendant ce temps, le nouveau build réussit.

Étape 6 : Vérification des fuites — script d'audit prêt à l'emploi

Objectif de cette étape : s'assurer que les identifiants ne sont pas dans les artefacts, les journaux et le dépôt, et automatiser cette vérification.

Où chercher

• Artefacts du build : fichiers compilés, rapports, dumps.
• Journaux du pipeline, y compris les anciennes exécutions.
• Historique du dépôt git.
• Caches et fichiers temporaires du runner.

Recherche dans les artefacts et les journaux

Téléchargez les artefacts et les journaux dans un dossier local et effectuez une recherche avec des marqueurs caractéristiques : nom d'utilisateur, partie du mot de passe, mot Basic et en-tête d'autorisation.

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

Le script recherche l'en-tête d'autorisation, les chaînes base64 après le mot Basic, le motif de connexion dans netrc et le signe de mot de passe dans l'URL avant le symbole @. Toute correspondance est une raison d'enquêter.

Recherche dans l'historique git

Le mot de passe a pu entrer dans un ancien commit. Vérifiez tout l'historique.

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ Attention : Si le mot de passe est trouvé dans l'historique git, supprimer simplement le fichier ne suffit pas — il restera dans les anciens commits. Il faut réécrire l'historique avec des outils spéciaux et, surtout, changer immédiatement le mot de passe. Considérez ce mot de passe comme compromis.

Automatisation dans le pipeline

Ajoutez un job séparé qui scanne les artefacts construits avant la publication et échoue en cas de détection. Ce garde-fou attrape la fuite avant qu'elle ne parte à l'extérieur.

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

Conseil : En complément, intégrez des scanners de secrets prêts à l'emploi à l'étape pre-commit en local. Ils attrapent les identifiants avant même le commit, les empêchant d'entrer dans le dépôt.

Résultat attendu : l'audit manuel et le job automatique confirment que les identifiants ne sont nulle part.

✅ Vérification : exécutez le script d'audit — il doit se terminer sans correspondance. Ensuite, placez délibérément une chaîne de test avec le marqueur Basic dans un artefact et vérifiez que le script la trouve et échoue.

Étape 7 : Check-list avant de déployer le pipeline

Objectif de cette étape : passer la vérification finale avant d'activer le pipeline.

Passez en revue la liste et cochez chaque point. Si un seul n'est pas coché, ne déployez pas le pipeline.

1. Le mot de passe proxy n'est écrit nulle part dans une URL du type user:pass@host.
2. L'identifiant et le mot de passe sont stockés uniquement dans les secrets CI, pas dans les fichiers du dépôt.
3. Les secrets sont marqués comme masquables et protégés.
4. Les secrets ne sont pas accessibles aux builds de forks et de pull requests externes.
5. Les drapeaux de mode verbeux et de trace sont retirés des commandes.
6. Le niveau de journalisation des bibliothèques HTTP n'est pas DEBUG.
7. Les variables de débogage comme NODE_DEBUG sont absentes de l'environnement du runner.
8. Les fichiers netrc et curlrc sont créés à la volée et ont les droits 600.
9. Les fichiers d'identifiants sont supprimés à la fin du build ou se trouvent sur un runner éphémère.
10. Le pipeline contient un job de vérification des fuites.
11. L'historique git est vérifié et ne contient pas d'identifiants.
12. Une procédure de rotation du mot de passe existe.

Conseil : Conservez cette check-list comme modèle et joignez-la à chaque nouveau pipeline utilisant un proxy. L'uniformité réduit le nombre d'erreurs.

✅ Vérification : les douze points sont cochés. Ce n'est qu'à ce moment que le pipeline est prêt à être déployé.

Vérification du résultat : comment s'assurer que tout fonctionne

Rassemblons la vérification finale en un scénario unique.

Check-list de fonctionnement

• Le build passe avec succès par le proxy Proxeon et obtient les réponses attendues.
• Dans le journal du build, il n'y a pas de mot de passe, d'identifiant, de chaînes base64 d'autorisation ni d'URL complète du proxy.
• Dans la liste des processus du runner pendant la requête, le mot de passe est absent.
• Les artefacts sont propres, le script d'audit ne trouve pas de correspondance.
• Les secrets sont masqués même lors d'un echo intentionnel.

Comment tester

1. Lancez un pipeline complet de bout en bout.
2. Ouvrez le journal et recherchez le nom d'utilisateur — aucune correspondance ne doit apparaître.
3. Téléchargez les artefacts et exécutez le script d'audit dessus.
4. Vérifiez le job de détection des fuites — il doit passer au vert.

Indicateurs de succès

Le succès ressemble à ceci : le build est vert, les requêtes passent par le proxy, et la recherche dans tous les endroits possibles ne trouve aucun fragment d'identifiants. Si c'est le cas, vous avez atteint l'objectif du guide.

Erreurs typiques et solutions

Passons en revue les problèmes fréquents avec le schéma problème, cause, solution.

Problème 1 : le mot de passe est toujours visible dans le journal

Cause : la variable a été créée comme variable ordinaire et non comme secret, ou n'est pas marquée comme masquable.

Solution : déplacez la valeur dans la section des secrets, activez le masquage et vérifiez que le nom de la variable correspond dans la configuration et dans le stockage.

Problème 2 : le masquage ne fonctionne pas dans GitLab

Cause : le mot de passe contient des caractères ou des retours à la ligne non autorisés pour le masquage.

Solution : changez le mot de passe pour une chaîne faite de lettres, de chiffres et de caractères autorisés, d'une longueur suffisante, conforme aux exigences de masquage.

Problème 3 : curl ne lit pas netrc

Cause : le fichier a de mauvais droits ou n'est pas dans le répertoire personnel.

Solution : définissez les droits 600 avec la commande chmod et assurez-vous que le chemin du fichier correspond à celui attendu, ou spécifiez le chemin avec le drapeau netrc-file.

Problème 4 : mot de passe dans la stack trace en cas d'erreur

Cause : l'URL du proxy est construite avec les identifiants et le client l'imprime dans l'exception.

Solution : passez à netrc ou à des champs séparés pour l'identifiant et le mot de passe, afin que l'URL ne contienne pas d'identifiants, et n'imprimez que le message d'erreur.

Problème 5 : l'ancien mot de passe continue d'être utilisé après la rotation

Cause : un fichier netrc ou curlrc en cache est resté sur le runner.

Solution : supprimez les fichiers d'identifiants à la fin de chaque build et utilisez des runners éphémères où le système de fichiers est nettoyé entre les exécutions.

Problème 6 : le secret a fui dans un fork-pull-request

Cause : un mode donnant accès aux secrets aux PR externes est activé.

Solution : désactivez ce mode, lancez les builds contenant des secrets uniquement pour les branches de confiance, et vérifiez les PR externes sans accès au proxy.

Problème 7 : mot de passe trouvé dans l'historique git

Cause : des identifiants ont été commités dans un fichier de configuration à un moment donné.

Solution : changez immédiatement le mot de passe, puis réécrivez l'historique du dépôt en supprimant les données sensibles de tous les commits.

Fonctionnalités supplémentaires : protection avancée

Une fois la protection de base en place, vous pouvez la renforcer.

Gestionnaire de secrets externe

Au lieu de stocker les identifiants dans le système CI lui-même, connectez un gestionnaire de secrets externe. Le pipeline obtient les identifiants via un jeton à courte durée de vie uniquement pour la durée du build. Ainsi, les secrets ne restent pas dans les paramètres du projet en permanence.

Jetons à courte durée de vie au lieu du mot de passe

Si l'infrastructure Proxeon et votre schéma d'accès le permettent, préférez des jetons temporaires avec une durée de vie limitée. Même en cas de fuite, un tel jeton devient rapidement inutile.

Séparation des identifiants par environnement

Utilisez des identifiants différents pour les builds de test et de production. La compromission des identifiants de test n'affectera pas les processus de production.

Conseil : Configurez une alerte en cas d'activité anormale sur le compte proxy. Une augmentation soudaine des requêtes ou des connexions depuis des sources inattendues est un signal de fuite potentielle, nécessitant une rotation immédiate.

Rotation automatique

Les équipes avancées automatisent la rotation selon un calendrier : un script crée de nouveaux identifiants, met à jour le secret et révoque les anciens sans intervention humaine. Commencez par une procédure manuelle, puis ajoutez l'automatisation une fois le processus rodé.

FAQ : questions fréquentes

Puis-je simplement me fier au masquage du CI et ne pas m'inquiéter ?

Non. Le masquage n'attrape que les correspondances exactes de la valeur connue. L'en-tête en base64 ou une sortie partielle peut passer à travers. Combinez le masquage avec l'abandon du mot de passe dans l'URL et la désactivation des journaux verbeux.

Qu'est-ce qui est plus sûr : variable d'environnement ou fichier netrc ?

Le fichier netrc avec les droits 600 est préférable pour curl, car la valeur n'apparaît même pas dans la liste des processus. Pour le code Python et Node, les variables d'environnement, lues à l'intérieur du processus, sont plus pratiques. Les deux options sont sûres si elles sont manipulées avec précaution.

Dois-je supprimer le fichier d'identifiants après le build ?

Oui, si le runner est réutilisé. Sur les runners éphémères, où la machine est détruite après le build, c'est moins critique, mais la suppression à la fin est une bonne habitude dans tous les cas.

Que faire si le mot de passe proxy contient des caractères spéciaux ?

Dans netrc et dans les champs séparés, les caractères spéciaux ne posent généralement pas de problème. Les problèmes surviennent précisément lors de l'insertion dans une URL, où des caractères comme @ et : cassent l'analyse. C'est un argument de plus pour ne pas mettre le mot de passe dans l'URL.

Est-ce que requests imprime les identifiants tout seul ?

Par défaut, non. La fuite se produit lorsque la journalisation DEBUG d'urllib3 est activée ou lorsque vous imprimez l'objet de configuration du proxy. Gardez la journalisation sur WARNING et n'imprimez pas la configuration en entier.

Le mot de passe est-il visible dans la liste des processus avec le drapeau proxy-user ?

Oui, un drapeau dans la ligne de commande est visible dans ps. C'est pourquoi pour curl, préférez netrc ou curlrc, où les identifiants ne sont pas passés en argument.

À quelle fréquence changer le mot de passe proxy ?

Une rotation planifiée est raisonnable régulièrement, par exemple tous les trimestres, et immédiatement en cas de suspicion de fuite. La procédure de rotation de l'étape 5 vous aidera à le faire rapidement.

Puis-je stocker les identifiants dans un fichier chiffré dans le dépôt ?

Techniquement oui, mais cela complique le processus et crée un risque de fuite de la clé de chiffrement. Les secrets CI et les gestionnaires de secrets externes résolvent le problème plus simplement et plus sûrement. N'inventez pas votre propre stockage sans nécessité.

Que faire si une fuite a déjà eu lieu ?

Agissez dans l'ordre : changez immédiatement le mot de passe proxy, révoquez les anciens identifiants, trouvez tous les endroits de fuite avec le script d'audit, réécrivez l'historique git si nécessaire et analysez la cause pour qu'elle ne se reproduise pas.

Ces recommandations s'appliquent-elles aux runners Windows ?

Oui, les principes sont les mêmes. La syntaxe diffère : au lieu d'export, utilisez la méthode de définition des variables pour votre shell, et au lieu de chmod, configurez les droits via les propriétés du fichier. La logique de stockage et de désactivation des journaux est identique.

Conclusion

Vous êtes passé d'une habitude peu sûre d'écrire le mot de passe dans l'URL à une protection complète des identifiants proxy dans le CI/CD. Rappelons ce qui a été fait.

Vous avez appris à reconnaître les cinq endroits de fuite et abandonné le mot de passe dans l'adresse du proxy. Vous avez déplacé les identifiants dans des variables d'environnement et des fichiers netrc, curlrc et configs client avec les droits 600. Vous avez configuré des secrets dans GitHub Actions, GitLab CI et Jenkins avec masquage et restriction de portée. Vous avez désactivé les journaux détaillés qui impriment l'en-tête d'autorisation dans curl, Python requests et Node. Vous avez maîtrisé la rotation du mot de passe sans arrêt des builds et créé un script d'audit des fuites prêt à l'emploi. Enfin, vous avez passé la check-list finale avant déploiement.

Que faire ensuite. Intégrez la check-list comme étape obligatoire de revue pour tous les pipelines utilisant le proxy Proxeon. Ajoutez le job de détection des fuites à tous les projets. Passez progressivement à un gestionnaire de secrets externe et aux jetons à courte durée de vie, une fois le processus de base devenu une habitude.

Où aller plus loin. Étudiez les pratiques de gestion des secrets à l'échelle de l'organisation, la rotation automatique et la surveillance des anomalies sur le compte proxy. La sécurité des identifiants n'est pas une configuration ponctuelle, mais une discipline d'ingénierie constante. Mais maintenant, vous avez une base solide sur laquelle construire tout le reste. Bonnes et sûres compilations.