Partager des secrets dans GitHub Actions — sans Vault

Tu peux partager des secrets dans GitHub Actions sans HashiCorp Vault en utilisant la GitHub Action de Vaulted, qui crée des liens chiffrés et autodestructeurs sans aucune infrastructure. Elle utilise le chiffrement côté client AES-256-GCM et fonctionne comme une seule étape de workflow — sans serveur de gestionnaire de secrets ni configuration cloud.

Les pipelines CI ont sans cesse besoin d'identifiants temporaires. Une clé de déploiement qui ne devrait vivre que le temps d'une seule exécution. Un token transmis entre deux dépôts pendant une migration. Un identifiant renouvelé dans un workflow et consommé dans un autre.

Le conseil habituel, c'est : « utilise un gestionnaire de secrets ». Mais mettre en place HashiCorp Vault ou configurer AWS Secrets Manager juste pour transmettre un seul identifiant entre des workflows, c'est comme louer un entrepôt pour poster une lettre.

Les secrets de dépôt GitHub gèrent bien le cas statique — clés d'API à longue durée de vie, tokens de déploiement, identifiants de comptes de service. Mais ils ne suffisent pas dès qu'il s'agit de quelque chose de temporaire ou de dynamique.

Le manque : le partage temporaire de secrets en CI/CD

Les secrets de dépôt sont conçus pour des valeurs qui changent rarement et qui sont consommées par un seul dépôt. Ils ne couvrent pas :

Les transmissions à usage unique lors de la rotation de clés — Tu renouvelles un identifiant dans un workflow et un autre workflow (ou une autre équipe) doit récupérer la nouvelle valeur exactement une fois.
Le partage d'identifiants entre dépôts — Deux dépôts doivent échanger un token à courte durée de vie, mais aucun ne devrait le stocker durablement.
L'accès limité dans le temps pour un prestataire — Un token CI qui devrait expirer une fois la fenêtre de déploiement d'un prestataire fermée.
Savoir quand un secret a été consommé — Les secrets de dépôt n'offrent aucune visibilité sur le fait qu'une valeur a été lue, ni sur le moment où elle l'a été.

Ce sont des problèmes temporaires qui appellent une solution temporaire.

Une approche plus légère : des liens chiffrés et autodestructeurs

La Vaulted GitHub Action te permet de créer et de récupérer des secrets chiffrés et autodestructeurs directement depuis tes workflows — sans aucune infrastructure à gérer.

Créer un secret :

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

L'étape produit une URL contenant le secret chiffré. La clé de chiffrement vit dans le URL fragment, elle ne touche donc jamais les serveurs de Vaulted.

Récupérer un secret :

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Après récupération, le lien est consommé et le texte chiffré côté serveur est supprimé. Le secret n'existe que dans la mémoire du runner, pour la durée de ce job.

Modèle de sécurité

Trois propriétés rendent cela sûr pour un usage en CI/CD :

Chiffrement zero-knowledge. Le secret est chiffré avec AES-256-GCM à l'intérieur du runner GitHub, avant de quitter le processus. La clé de chiffrement est intégrée dans le URL fragment, qui n'est jamais envoyé au serveur. Vaulted ne stocke que du texte chiffré qu'il ne peut pas déchiffrer. C'est du chiffrement côté client appliqué au CI/CD.
Masquage automatique des logs. L'action appelle core.setSecret avant core.setOutput, enregistrant chaque ligne de la valeur du secret auprès du masqueur de logs de GitHub. Les secrets multilignes sont masqués ligne par ligne, si bien que même les correspondances partielles sont caviardées des logs de workflow.
Liens autodestructeurs. La limite de consultations et l'expiration par durée sont appliquées côté serveur. Un secret créé avec views: 1 et expires: 1h est définitivement supprimé après la première récupération ou au bout d'une heure — selon ce qui survient en premier.

Quand utiliser ceci plutôt qu'un gestionnaire de secrets

Scénario	Gestionnaire de secrets	Vaulted Action
Identifiants de production à longue durée de vie	Oui	Non
Configuration d'exécution d'app (URLs de BDD, clés d'API)	Oui	Non
Transmission unique d'identifiant entre workflows	Surdimensionné	Oui
Partage temporaire de token entre dépôts	Surdimensionné	Oui
Accès CI limité dans le temps pour un prestataire	Surdimensionné	Oui
Distribution d'identifiant après une rotation	Surdimensionné	Oui

Les gestionnaires de secrets sont l'outil adapté aux secrets que les applications consomment à l'exécution. Vaulted est fait pour la transmission — le moment où un identifiant passe d'un endroit à un autre et ne devrait pas persister.

Pour commencer

Ajoute l'action à n'importe quel workflow :

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Tu la trouveras sur le GitHub Marketplace. Les secrets créés par l'action sont compatibles avec l'application web et la CLI — tout ce qui est créé dans l'un peut être récupéré depuis l'autre.

Pas de serveur Vault. Pas de politiques IAM. Pas d'infrastructure. Juste des liens chiffrés qui s'autodétruisent.

Le manque : le partage temporaire de secrets en CI/CD

Une approche plus légère : des liens chiffrés et autodestructeurs

Modèle de sécurité

Quand utiliser ceci plutôt qu'un gestionnaire de secrets

Pour commencer

Articles liés