Gestion des secrets GitHub Actions : protéger les clés API et les mots de passe dans les workflows

By Mirko Peters · 2026-10-26

Découvrez comment sécuriser vos pipelines CI/CD grâce à une utilisation appropriée des secrets GitHub Actions. Découvrez les bonnes pratiques pour gérer les clés API et les jetons d’accès en toute sécurité.

Automatically translated with AI from the original post. Read the English original

Lorsque votre automatisation s’exécute entièrement sans supervision dans le cloud, la sécurité de vos identifiants devient essentielle. Bien gérer les secrets GitHub Actions permet de garder vos clés API, mots de passe de déploiement et jetons d’accès hors de votre code source, tout en les rendant facilement accessibles aux workflows qui en ont besoin pour compiler et livrer vos projets.

Points clés

• Ne codez jamais en dur des mots de passe, clés API ou jetons d’accès sensibles directement dans vos fichiers YAML de workflow.
• GitHub propose trois niveaux de secrets : les secrets de dépôt, les secrets d’organisation et les secrets d’environnement.
• Les secrets sont chiffrés avant même d’atteindre GitHub et sont masqués automatiquement dans les journaux d’exécution.
• Les secrets d’environnement peuvent imposer une approbation humaine avant que les identifiants de déploiement ne deviennent accessibles à un job.
• Appliquez toujours le principe du moindre privilège, en n’accordant à chaque secret que le plus petit ensemble d’autorisations requis.

Pourquoi les identifiants en clair échouent dans les pipelines CI/CD

Il est tentant, pour un développeur pressé de mettre en place un nouveau pipeline, de coller une clé API directement dans le fichier de configuration du workflow. Après tout, si le workflow est privé, qui pourrait le voir ? Cette approche introduit de graves failles de sécurité. Les fichiers de workflow sont versionnés : chaque révision, chaque commit et chaque branche conserve un enregistrement permanent de tout ce qui a été écrit dans ces documents YAML.

De plus, les dépôts changent souvent de permissions, passent du privé au public ou sont forkés par des contributeurs. Si vos identifiants existent sous forme de chaînes en clair dans vos fichiers de configuration, une seule erreur de configuration des autorisations peut exposer l’ensemble de votre environnement de production. Traiter vos fichiers de configuration uniquement comme des instructions, tout en stockant les données sensibles dans un coffre chiffré et découplé, constitue la règle fondamentale de la sécurité cloud moderne.

Les trois niveaux de secrets GitHub

GitHub reconnaît que les différents identifiants ont des périmètres différents. Pour aider les développeurs à gérer le contrôle d’accès de manière efficace, la plateforme permet de configurer les secrets à trois niveaux organisationnels distincts.

Secrets au niveau du dépôt

Les secrets de dépôt appartiennent exclusivement à un seul projet. Si vous développez une application autonome ou gérez un plugin unique, un secret de dépôt verrouille vos chaînes de connexion et jetons de déploiement sur cet espace de travail précis. Ils ne peuvent pas être utilisés par d’autres projets de votre organisation.

Secrets au niveau de l’organisation

Lorsque plusieurs dépôts d’une entreprise doivent accéder aux mêmes ressources partagées, comme un registre de conteneurs central ou un certificat d’entreprise de signature de code, les secrets d’organisation vous évitent de dupliquer les entrées. Les administrateurs peuvent définir des stratégies et cibler les dépôts ou équipes spécifiques autorisés à hériter de ces identifiants à l’échelle de l’organisation.

Secrets au niveau de l’environnement

Les secrets d’environnement lient les identifiants à des cibles de déploiement spécifiques, comme les environnements de préproduction ou de production. C’est là que vous stockez les clés nécessaires pour toucher aux systèmes en service. Point crucial : les secrets d’environnement permettent de définir des relecteurs obligatoires, afin qu’un humain doive approuver manuellement une exécution de déploiement avant que les identifiants de production ne soient libérés et transmis au runner.

Comment GitHub protège vos données en transit

La sécurité ne se limite pas à l’endroit où les secrets sont stockés ; elle concerne aussi la manière dont ils circulent pendant l’exécution. Les secrets sont chiffrés sur votre poste local avant d’être transmis à GitHub, de sorte qu’ils ne transitent jamais en clair sur le réseau. Une fois enregistrés, ils restent totalement masqués dans l’interface des paramètres du dépôt.

Lors de l’exécution d’un workflow, vous devez transmettre explicitement un secret à une étape ou à une action, par son nom, en utilisant la syntaxe d’expression suivante : ${{ secrets.DATABASE_URL } }. Ainsi, une action tierce malveillante ou mal écrite issue de la marketplace ne peut pas se servir automatiquement de chaque identifiant de votre dépôt : elle ne reçoit que ce que vous lui transmettez explicitement.

Par ailleurs, GitHub analyse automatiquement les journaux de sortie des tâches pour masquer les chaînes sensibles. Si votre script affiche accidentellement une valeur secrète dans la console, GitHub tente de remplacer ses caractères par des astérisques. Toutefois, comme les scripts peuvent manipuler ou encoder des chaînes avant de les afficher, le masquage des journaux ne remplace en aucun cas l’écriture de code sécurisé.

Bonnes pratiques pour une automatisation sécurisée

Une gestion robuste des secrets GitHub Actions suppose d’adopter certaines habitudes au quotidien. D’abord, distinguez toujours un paramètre de configuration d’un secret. Si une valeur n’est qu’une adresse de site web publique, un nom d’environnement ou un indicateur de fonctionnalité non sensible, conservez-la en clair dans votre fichier YAML afin que votre équipe puisse facilement comprendre le fonctionnement du pipeline. Réservez la fonctionnalité des secrets exclusivement aux données qui doivent rester confidentielles.

Ensuite, appliquez le principe du moindre privilège. Générez des jetons d’accès granulaires avec les dates d’expiration les plus courtes possible et la portée d’autorisations la plus restreinte. Si un jeton de déploiement n’a besoin que d’écrire dans un seul bucket S3 précis, ne lui accordez pas de droits d’administration sur l’ensemble de votre infrastructure cloud.

Conclusion

Maîtriser la gestion des secrets GitHub Actions transforme vos pipelines CI/CD, qui pouvaient représenter des failles de sécurité, en moteurs d’automatisation robustes, dignes des grandes entreprises. En séparant vos identifiants de votre code et en vous appuyant sur des contrôles d’accès à plusieurs niveaux, vous pouvez livrer vos logiciels rapidement sans sacrifier la sécurité.

Pour explorer les bases de la création de workflows automatisés, consultez Listen to the full episode. Écoutez la discussion complète pour en savoir plus sur la configuration des déclencheurs, des tâches et des runners pour vos environnements cloud modernes !

Questions fréquentes

Peut-on lire un secret GitHub Actions dans une pull request provenant d’un fork ?

Par défaut, GitHub empêche les pull requests émanant de contributeurs externes (forks) d’accéder aux secrets de votre dépôt, afin de se protéger contre l’exécution de code malveillant qui pourrait voler vos identifiants.

Comment transmettre un secret d’un workflow à une étape spécifique ?

Vous transmettez des secrets à votre workflow en utilisant le contexte « env » au niveau d’une étape ou d’un job, en associant le secret GitHub à une variable d’environnement, par exemple env: API_KEY: ${{ secrets.MY_API_KEY } }.

Les secrets GitHub Actions sont-ils garantis masqués dans les journaux ?

GitHub masque automatiquement les valeurs secrètes connues dans les journaux d’exécution, mais ce mécanisme n’offre aucune garantie absolue. Si une valeur secrète est manipulée, encodée ou transformée avant d’être affichée, certaines parties pourraient néanmoins être exposées.

Quelle est la différence entre les secrets de dépôt et les secrets d’environnement ?

Les secrets de dépôt sont disponibles pour tous les workflows d’un dépôt donné, tandis que les secrets d’environnement sont liés à des environnements de déploiement spécifiques (comme la préproduction ou la production) et peuvent exiger une validation manuelle avant utilisation.