Un pipeline de déploiement d'API manipule beaucoup de secrets : identifiants d'administration de la passerelle, mots de passe des backends, certificats, secrets de clients OAuth, jetons d'accès aux dépôts. Dans les chaînes que nous auditons, quelle que soit la passerelle, on les retrouve souvent dans des endroits qui n'ont pas été conçus pour cela : variables de la CI, fichiers de configuration versionnés, paramètres de jobs, voire journaux d'exécution.
Cet article décrit la trajectoire que nous suivons pour sortir ces secrets des pipelines. Elle s'appuie sur un coffre-fort de secrets (HashiCorp Vault, ou l'équivalent proposé par votre plateforme) et sur des pratiques indépendantes des outils.
Pourquoi les variables de CI ne suffisent pas
Les outils de CI proposent tous un mécanisme de variables protégées ou masquées. C'est mieux que rien, mais cela laisse plusieurs problèmes entiers :
- le masquage n'est pas une protection : il évite l'affichage accidentel d'une valeur dans les journaux, mais un script peut la transformer, l'écrire dans un fichier ou l'envoyer ailleurs ;
- les secrets sont statiques : ils vivent des mois, parfois des années, et leur rotation est manuelle ;
- l'accès est large : toute personne capable de modifier le pipeline peut généralement lire les variables qu'il utilise ;
- la traçabilité est faible : on sait qu'un job a utilisé un secret, rarement qui l'a déclenché et pourquoi.
Le principe : le pipeline ne possède aucun secret
L'objectif est que le pipeline ne stocke aucun secret de manière permanente. Il les obtient au moment où il en a besoin, auprès d'un coffre-fort, pour une durée limitée, et seulement ceux dont il a besoin.
1. Le dépôt ne contient que des références
Dans le dépôt de l'API, on ne trouve jamais une valeur, seulement une référence : « le mot de passe du backend de facturation en recette est au chemin X du coffre-fort ». La relecture d'une merge request montre quel secret est utilisé, sans l'exposer.
2. La CI s'authentifie par son identité, pas par un secret
Le paradoxe classique : pour lire les secrets dans le coffre-fort, le pipeline a besoin… d'un secret. On le résout par la fédération d'identité : de nombreux outils de CI peuvent émettre un jeton signé qui décrit le job (projet, branche, environnement), que le coffre-fort vérifie avant d'accorder un accès. Plus de secret maître stocké dans la CI. Les capacités exactes dépendent de votre outil et de sa version : à vérifier.
3. Des droits minimaux, par environnement
Le job qui déploie en recette ne doit pas pouvoir lire les secrets de production. Les politiques du coffre-fort sont écrites par projet et par environnement, et l'accès aux secrets de production est réservé aux jobs lancés depuis la branche protégée, après les validations prévues.
4. Des secrets à durée de vie courte quand c'est possible
Certains coffres-forts savent générer des identifiants dynamiques : un compte de base de données ou un jeton créé pour le job et révoqué après. Toutes les passerelles et tous les backends ne s'y prêtent pas. Quand ce n'est pas possible, on vise au moins une rotation régulière et automatisée des secrets statiques, en appliquant le principe du recouvrement pour éviter les coupures.
Traçabilité : qui a fait quoi, vraiment
Dans beaucoup de chaînes, toutes les actions sur la passerelle sont faites par un compte technique unique. En cas d'incident, le journal de la passerelle indique « compte CI », ce qui n'aide personne. Nous visons une traçabilité nominative de bout en bout :
- chaque exécution du pipeline est rattachée à la personne qui l'a déclenchée ou approuvée ;
- le coffre-fort journalise chaque lecture de secret, avec l'identité du job ;
- lorsque la passerelle le permet, l'action est effectuée avec une identité qui reflète l'utilisateur, ou au minimum corrélée à lui.
Le but n'est pas de surveiller les personnes, mais de pouvoir reconstituer une séquence d'événements sans hypothèse.
Ne pas laisser fuir les secrets en route
Sortir les secrets du dépôt ne sert à rien s'ils réapparaissent ailleurs. Les points de vigilance que nous contrôlons :
- les journaux d'exécution : pas d'affichage de commandes contenant des secrets, pas de mode verbeux activé en production ;
- les fichiers temporaires : un secret écrit sur le disque d'un agent de build doit être supprimé, et les agents partagés sont à éviter pour les environnements sensibles ;
- les artefacts : une archive de configuration ne doit pas embarquer de valeurs sensibles ;
- l'historique Git : un secret déjà commité doit être considéré comme exposé et renouvelé, même après suppression.
Un outil de détection de secrets exécuté à chaque merge request complète utilement le dispositif.
La trajectoire, étape par étape
Tout faire d'un coup est rarement réaliste. L'ordre que nous recommandons :
- inventorier les secrets utilisés par les pipelines et leurs emplacements actuels ;
- renouveler ceux qui ont été exposés (historique Git, journaux) ;
- déplacer les secrets dans le coffre-fort, en laissant des références dans le dépôt ;
- fédérer l'identité de la CI pour supprimer le secret maître ;
- restreindre les politiques par projet et par environnement ;
- automatiser la rotation, puis introduire les secrets dynamiques là où c'est possible.
La durée de cette trajectoire dépend de la taille du patrimoine et se définit avec les équipes.
Ce qu'il faut retenir
Un pipeline de déploiement d'API ne devrait posséder aucun secret de façon permanente : il les obtient à l'exécution, avec son identité, pour un périmètre minimal, et chaque accès est tracé. Ces principes ne dépendent ni de la passerelle ni de l'outil de CI. Ils réduisent la surface d'exposition et rendent les rotations, et les audits, beaucoup moins pénibles.
À côté du conseil, CAB Ingénierie édite STOA, iPaaS souverain, plateforme d'API et d'intégration.
Parlons de votre projet
Vos pipelines d'API manipulent encore des secrets statiques, ou vous préparez un audit ? Décrivez-nous votre contexte en quelques lignes : cab-ingenierie.com · contact@cab-ingenierie.com