Secrets GitHub Actions avec Crunu et OIDC

Ce que fait Crunu dans GitHub Actions

Une étape du workflow lance votre commande via crunu run. L’agent crunu se connecte avec un jeton de service, vérifie les signatures de tout ce que le serveur envoie, déchiffre les variables dans sa propre mémoire et lance la commande avec elles. Rien n’est écrit sur le disque.

crunu run --env web-app/staging -- npm test

Le jeton ne reçoit que les environnements que vous lui accordez. Avec une liaison CI (OIDC), il lui faut en plus un jeton GitHub récent pour le dépôt, la branche et l’environnement de déploiement que vous avez définis : un CRUNU_TOKEN qui a fuité ne peut donc pas se connecter seul. crunu demande lui-même ce jeton GitHub, et le serveur refuse un jeton déjà utilisé.

Configuration

1. Dans Crunu, ouvrez Service tokens et choisissez New service token. Donnez-lui un nom comme github-actions-web-app, accordez web-app / staging et gardez le bail par défaut de 30 jours. Le jeton cesse de fonctionner si aucune exécution ne l’utilise pendant plus longtemps que le bail, et chaque exécution le prolonge.
2. Le jeton n’est affiché qu’une seule fois. Enregistrez-le immédiatement comme secret de dépôt CRUNU_TOKEN.
3. Copiez les valeurs du bloc CI setup de la page du jeton dans des variables de dépôt : CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 et CRUNU_BINARY_SHA256. Elles proviennent du manifeste de version signé. Dans le cloud, CRUNU_SERVER vaut https://app.crunu.com.
4. Facultatif : ajoutez une liaison CI (OIDC) sur la page du jeton. Choisissez le fournisseur GitHub et définissez repository, ref et, pour un jeton de production, environment.

Exemple de workflow

Ce job installe une version figée de crunu, vérifie le SHA-256 de l’installateur avant de le lancer, puis exécute les tests avec les variables de staging.

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      id-token: write     # only if the token has a CI binding (OIDC)
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Install crunu
        run: |
          curl -sSf "${{ vars.CRUNU_INSTALL_URL }}" -o /tmp/crunu-install.sh
          echo "${{ vars.CRUNU_INSTALL_SHA256 }}  /tmp/crunu-install.sh" | sha256sum -c -
          sh /tmp/crunu-install.sh --version "${{ vars.CRUNU_VERSION }}" --sha256 "${{ vars.CRUNU_BINARY_SHA256 }}" --user-install
      - name: Tests
        env:
          CRUNU_TOKEN: ${{ secrets.CRUNU_TOKEN }}
          CRUNU_SERVER: ${{ vars.CRUNU_SERVER }}
        run: exec crunu run --env web-app/staging -- npm test

Pour un jeton de production, la liaison CI (OIDC) pourrait exiger :

• repository : kiteline/web-app
• ref : refs/heads/main
• environment : production

L’audience est l’adresse de votre serveur Crunu. crunu demande à GitHub un jeton avec cette audience : c’est pourquoi le job a besoin de id-token: write.

L’action setup-crunu

Les mêmes étapes d’installation existent aussi sous forme d’une petite action composite, setup-crunu. Elle n’est pas publiée sur GitHub Marketplace. Gardez une copie de ses deux fichiers dans .github/actions/setup-crunu/ de votre dépôt : le code qui touche aux secrets de votre pipeline passe ainsi par la même relecture que le reste de votre code. Si vous la publiez plutôt dans un dépôt séparé, figez-la sur un SHA de commit complet, pas sur un tag.

      - uses: actions/checkout@v4
      - uses: ./.github/actions/setup-crunu
        with:
          version: ${{ vars.CRUNU_VERSION }}
          install-url: ${{ vars.CRUNU_INSTALL_URL }}
          install-sha256: ${{ vars.CRUNU_INSTALL_SHA256 }}
          sha256: ${{ vars.CRUNU_BINARY_SHA256 }}
      - env:
          CRUNU_TOKEN: ${{ secrets.CRUNU_TOKEN }}
          CRUNU_SERVER: ${{ vars.CRUNU_SERVER }}
        run: exec crunu run --env web-app/staging -- npm test

L’action ne contacte pas le serveur Crunu. Elle se contente d’installer crunu et de l’ajouter au PATH pour les étapes suivantes.

Gardez le jeton hors de portée

• Définissez CRUNU_TOKEN dans le env de la seule étape qui lance crunu. Les variables définies au niveau du job ou du workflow atteignent toutes les étapes.
• Démarrez crunu avec exec. Le shell de l’étape est alors remplacé par crunu, et le jeton ne reste pas dans un processus que votre commande pourrait lire.
• La commande lancée sous crunu run ne reçoit jamais les propres identifiants de crunu, comme CRUNU_TOKEN ou CRUNU_OIDC_TOKEN.

Runners et sommes de contrôle

crunu fonctionne sur les runners Linux et macOS, en amd64 et arm64, runners auto-hébergés compris. Les runners Windows ne sont pas pris en charge. La somme de contrôle du bloc CI setup concerne Linux amd64. Pour les runners arm64 ou macOS, définissez des sommes de contrôle par plateforme à partir du manifest.json de la version, par exemple amd64=… et darwin-arm64=….

Production sans CI

La configuration que recommande Crunu garde les valeurs de production hors du pipeline. Le serveur de production fait tourner l’agent crunu et récupère lui-même son environnement, et le workflow ne fait que livrer le code et redémarrer le service. Voir systemd.

Révocation

Ouvrez le jeton et choisissez Revoke. Sa prochaine connexion est refusée, et une étape déjà en cours se termine avec ce qu’elle a reçu. Si le jeton a pu fuiter, révoquez-le, renouvelez les clés des environnements qui lui étaient accordés et réémettez chez leurs fournisseurs les valeurs qu’ils contiennent.

Voir aussi

• La CI/CD dans Crunu
• GitHub Actions dans la documentation
• Lier un jeton par OIDC
• Jetons de service