Pourquoi stocker des secrets dans Git est risqué et comment Semaphore Key Store résout le problème

Les développeurs codent encore en dur des jetons d’API, des mots de passe et des identifiants dans le code ou des fichiers .env, puis les poussent sur Git. Cela arrive autant sur des petits projets que sur des systèmes de production.

La raison est simple : sans un moyen propre de transmettre des secrets aux workflows d’automatisation et de déploiement, Git semble la seule option fiable. « On nettoiera plus tard. » Mais rien ne disparaît vraiment de Git.

Pourquoi Git est dangereux pour les secrets #

Git est un système de contrôle de version. Tout ce qui est commité entre dans l’historique. Vous pouvez retirer un jeton du dernier commit : les commits précédents l’ont déjà. Et l’historique se copie partout : dépôts locaux, agents d’automatisation, miroirs, forks. Dès qu’un secret atterrit dans un commit, il est exposé.

L’accès au dépôt est souvent plus large qu’il ne devrait l’être. Prestataires externes, contributeurs temporaires, forks de test : tous peuvent voir des identifiants qu’ils ne devraient pas.

GitHub et GitLab analysent activement la présence d’identifiants. Si la plateforme signale un jeton, considérez-le comme compromis et révoquez-le immédiatement.

Ce qui doit remplacer Git #

Un secret n’est pas un fichier statique. C’est un identifiant d’accès qui doit vivre hors du code, avec des droits contrôlés, une rotation possible et un isolement par environnement.

Vous pouvez faire tourner Vault ou OpenBao — mais cela implique de l’infrastructure, de la maintenance et du travail ops.

Semaphore intègre un Key Store directement dans ses workflows d’automatisation. Les secrets peuvent résider à l’un de ces deux endroits :

• la base chiffrée de Semaphore (par défaut)
• un magasin externe comme HashiCorp Vault, Devolutions ou OpenBao (fonctionnalité PRO)

Choisissez l’option intégrée simple ou branchez un système de secrets d’entreprise existant. Cela fonctionne sans configuration lourde.

Ce que stocke Key Store #

• jetons d’API
• clés SSH
• mots de passe
• variables d’environnement
• fichiers JSON et autres fichiers de configuration

Les secrets ne touchent jamais la base de code. Ils sont injectés uniquement au moment de l’exécution du job. Vous pouvez définir des identifiants distincts pour le dev, le staging et la production, et limiter l’accès à certains utilisateurs, équipes ou workflows.

En pratique #

Vous créez un Key Store, ajoutez un secret et y faites référence dans la configuration du workflow. Semaphore injecte la valeur à l’exécution.

Lors d’un déploiement AWS, par exemple, les clés d’accès n’existent que pendant ce job précis, uniquement sur l’agent qui l’exécute. Les développeurs ne voient pas le secret. Il ne passe jamais par Git.

Exemple #

Créez un secret via l’interface : Secrets → New Secret, puis ajoutez vos variables :

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Référencez le secret par son nom dans le workflow — Semaphore injecte les valeurs comme variables d’environnement à l’exécution :

blocks:
  - name: Deploy
    task:
      secrets:
        - name: aws-credentials
      jobs:
        - name: deploy
          commands:
            - aws s3 sync ./dist s3://my-bucket

Pour SSH, créez un secret contenant votre clé privée. Semaphore la place automatiquement dans ~/.ssh/ :

blocks:
  - name: Deploy via SSH
    task:
      secrets:
        - name: production-ssh-key
      jobs:
        - name: deploy
          commands:
            - ssh deploy@production-server "cd /app && git pull"

Key Store par rapport aux autres approches #

Méthode	Sécurisé	Visibilité	Révocable
.env dans Git	Non	Toute l’équipe	Non
GitHub Actions Secrets	Partiel	Selon le cas	Oui
Semaphore Key Store	Oui	Limitée	Oui

En plus : rotation des jetons sans toucher au code, contrôle d’accès par rôle ou équipe, secrets différents par environnement.

En résumé #

Tout jeton commité dans Git doit être traité comme compromis. L’historique se propage entre contributeurs, forks, miroirs et agents — chaque copie est un point d’exposition de plus.

Key Store garde les secrets hors des dépôts, les injecte uniquement à l’exécution et vous donne le contrôle sur la rotation et l’accès. Pour les équipes qui automatisent avec Ansible, Terraform, OpenTofu ou PowerShell, ce n’est pas une option : c’est le socle.

Twitter

Option 1

Secrets dans Git = secrets exposés. Pour toujours.

L’historique Git se réplique sur les forks, miroirs et agents CI. Un jeton commité est un jeton compromis pour une durée indéterminée.

Nous expliquons pourquoi cela continue — et comment Semaphore Key Store y remédie.

Option 2

Comment Semaphore Key Store gère les secrets :

→ Stocker jetons, clés SSH et variables d’environnement hors du dépôt

→ Référencer avec {{ your_secret }} dans la config du job

→ Injection à l’exécution, sur l’agent, pour ce job seulement

Les développeurs ne le voient pas. Cela ne touche jamais Git.
Article détaillé → [lien]

LinkedIn

Nous venons de publier une analyse du fonctionnement de Semaphore Key Store — et des raisons de son existence.

En bref : les secrets n’ont pas leur place dans Git. Jamais. Mais sans alternative sérieuse, les équipes continuent de les y mettre.

Key Store s’intègre directement aux workflows d’automatisation de Semaphore. Le déroulement :

1. Créer un Key Store dans l’interface
2. Ajouter vos secrets — jetons API, clés SSH, variables d’environnement, fichiers de config
3. Les référencer dans la config du job avec {{ your_secret }}
4. Semaphore les injecte à l’exécution, sur l’agent, pour ce job uniquement

Le développeur ne voit pas le secret. Il ne touche pas au dépôt. À la fin du job, il disparaît de l’environnement d’exécution.

Vous pouvez limiter l’accès par utilisateur, équipe ou environnement. Faire tourner un jeton sans modifier une ligne de code. Utiliser des identifiants séparés pour dev, staging et prod.

Pour les équipes Ansible, Terraform ou OpenTofu — c’est le maillon manquant entre « ça marche » et « c’est vraiment sécurisé ».

Article détaillé →