Secrets für GitHub Actions mit Crunu und OIDC

Was Crunu in GitHub Actions tut

Ein Workflow-Schritt führt Ihren Befehl über crunu run aus. Der Agent crunu meldet sich mit einem Service-Token an, prüft die Signaturen von allem, was der Server sendet, entschlüsselt die Variablen in seinem eigenen Arbeitsspeicher und startet den Befehl damit. Nichts wird auf die Festplatte geschrieben.

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

Das Token bekommt nur die Umgebungen, die Sie ihm freigeben. Mit einer CI-Bindung (OIDC) braucht es zusätzlich ein frisches GitHub-Token für das Repository, den Branch und die Deployment-Umgebung, die Sie festlegen, sodass sich ein geleaktes CRUNU_TOKEN nicht allein anmelden kann. crunu fordert dieses GitHub-Token selbst an, und der Server lehnt eines ab, das schon einmal verwendet wurde.

Einrichtung

1. Öffnen Sie in Crunu Service tokens und wählen Sie New service token. Geben Sie ihm einen Namen wie github-actions-web-app, gewähren Sie web-app / staging und behalten Sie die Standard-Lease von 30 Tagen. Das Token funktioniert nicht mehr, wenn es länger als die Lease von keinem Lauf genutzt wird, und jeder Lauf verlängert sie.
2. Das Token wird nur einmal angezeigt. Speichern Sie es sofort als Repository-Secret CRUNU_TOKEN.
3. Kopieren Sie die Werte aus dem Block CI setup auf der Seite des Tokens in Repository-Variablen: CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 und CRUNU_BINARY_SHA256. Sie stammen aus dem signierten Release-Manifest. In der Cloud ist CRUNU_SERVER gleich https://app.crunu.com.
4. Optional: Fügen Sie auf der Seite des Tokens eine CI-Bindung (OIDC) hinzu. Wählen Sie den Anbieter GitHub und setzen Sie repository, ref und, für ein Produktions-Token, environment.

Beispiel-Workflow

Dieser Job installiert eine festgelegte Version von crunu, prüft die SHA-256-Prüfsumme des Installers, bevor er ihn ausführt, und führt die Tests mit den Variablen von staging aus.

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

Für ein Produktions-Token könnte die CI-Bindung (OIDC) Folgendes verlangen:

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

Die Audience ist die Adresse Ihres Crunu-Servers. crunu fragt GitHub nach einem Token mit dieser Audience, deshalb braucht der Job id-token: write.

Die Action setup-crunu

Dieselben Installationsschritte gibt es auch als kleine Composite Action, setup-crunu. Sie ist nicht im GitHub Marketplace veröffentlicht. Bewahren Sie eine Kopie ihrer zwei Dateien in .github/actions/setup-crunu/ Ihres Repositorys auf, damit der Code, der die Secrets Ihrer Pipeline berührt, dasselbe Review durchläuft wie der Rest Ihres Codes. Veröffentlichen Sie sie stattdessen als eigenes Repository, pinnen Sie sie auf einen vollständigen Commit-SHA, nicht auf ein 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

Die Action kontaktiert den Crunu-Server nicht. Sie installiert nur crunu und fügt es für die nächsten Schritte zu PATH hinzu.

Das Token unerreichbar halten

• Setzen Sie CRUNU_TOKEN im env des einen Schritts, der crunu ausführt. Variablen auf Ebene des Jobs oder des Workflows erreichen jeden Schritt.
• Starten Sie crunu mit exec. Die Shell des Schritts wird dann durch crunu ersetzt, und das Token bleibt nicht in einem Prozess zurück, den Ihr Befehl lesen könnte.
• Der Befehl unter crunu run erhält nie die eigenen Zugangsdaten von crunu, etwa CRUNU_TOKEN oder CRUNU_OIDC_TOKEN.

Runner und Prüfsummen

crunu läuft auf Runnern mit Linux und macOS, auf amd64 und arm64, auch auf selbst gehosteten Runnern. Runner mit Windows werden nicht unterstützt. Die Prüfsumme im Block „CI setup“ gilt für Linux amd64. Für Runner mit arm64 oder macOS setzen Sie Prüfsummen pro Plattform aus der manifest.json des Releases, zum Beispiel amd64=… und darwin-arm64=….

Produktion ohne CI

Die von Crunu empfohlene Einrichtung hält Werte für production aus der Pipeline heraus. Der Produktionsserver führt den Agenten crunu aus und holt seine Umgebung selbst, und der Workflow liefert nur den Code und startet den Dienst neu. Siehe systemd.

Widerrufen

Öffnen Sie das Token und wählen Sie Revoke. Seine nächste Anmeldung wird abgelehnt, und ein bereits laufender Schritt läuft mit dem zu Ende, was er erhalten hat. Falls das Token geleakt sein könnte, widerrufen Sie es, rotieren Sie die Schlüssel der Umgebungen, die es erhalten hat, und stellen Sie die Werte darin bei ihren Anbietern neu aus.

Weiterführend

• CI/CD in Crunu
• GitHub Actions in der Dokumentation
• Ein Token per OIDC binden
• Service-Tokens