Variablen für GitLab CI aus Crunu, gebunden mit id_tokens

Was Crunu in GitLab CI tut

Ein Job führt Ihren Befehl über crunu run aus. Der Agent crunu meldet sich mit einem Service-Token an, prüft Signaturen, entschlüsselt die Variablen im 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 freigeben. Mit einer CI-Bindung (OIDC) stellt GitLab dem Job ein Token mit Ihrem Crunu-Server als Audience aus, und das Crunu-Token funktioniert nur zusammen damit, für den Projektpfad, die Ref und die Umgebung, die Sie festlegen. crunu liest das GitLab-Token selbst aus CRUNU_ID_TOKEN.

Einrichtung

1. Öffnen Sie in Crunu Service tokens und wählen Sie New service token. Gewähren Sie die Umgebungen, die der Job braucht. Das Token wird nur einmal angezeigt.
2. Öffnen Sie in GitLab Settings → CI/CD → Variables und fügen Sie CRUNU_TOKEN als maskierte, geschützte Variable hinzu.
3. Fügen Sie CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 und CRUNU_BINARY_SHA256 mit den Werten aus dem Block CI setup auf der Seite des Tokens hinzu. 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 GitLab und setzen Sie project_path, ref, ref_type und, für ein Produktions-Token, environment.

Beispiel-Job

Das Image des Jobs braucht sh und curl oder wget. Die Images node, python und alpine haben sie.

test:
  image: node:24
  id_tokens:
    CRUNU_ID_TOKEN:
      aud: https://app.crunu.com   # your Crunu server; only if the token has a CI binding (OIDC)
  script:
    - curl -sSf "$CRUNU_INSTALL_URL" -o /tmp/crunu-install.sh
    - echo "$CRUNU_INSTALL_SHA256  /tmp/crunu-install.sh" | sha256sum -c -
    - sh /tmp/crunu-install.sh --version "$CRUNU_VERSION" --sha256 "$CRUNU_BINARY_SHA256" --user-install
    - crunu run --env web-app/staging -- npm test

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

• project_path: kiteline/web-app
• ref: main
• ref_type: branch
• environment: production

Die Job-Vorlagen .crunu

Die Installationsschritte gibt es auch als Vorlagendatei mit zwei versteckten Jobs. Ihre Jobs erben sie mit extends:

• .crunu installiert eine festgelegte Version von crunu in before_script, prüft die SHA-256-Prüfsumme des Installers und des Binarys und gibt crunu version aus;
• .crunu-oidc tut dasselbe und fügt id_tokens hinzu, für Tokens mit CI-Bindung.

Bewahren Sie eine Kopie der Vorlage in Ihrem Repository auf, damit Änderungen daran mit Ihrem Code geprüft werden. Binden Sie sie stattdessen aus einem anderen GitLab-Projekt ein, pinnen Sie ref auf einen Commit, nicht auf einen Branch.

include:
  - local: ci/crunu.gitlab-ci.yml

test:
  image: node:24
  extends: .crunu
  script:
    - crunu run --env web-app/staging -- npm test

deploy:
  image: node:24
  extends: .crunu-oidc        # the production token has an OIDC rule: project_path, ref, environment
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - crunu run --env web-app/production -- npm run deploy

Das eigene before_script eines Jobs ersetzt das der Vorlage, denn extends führt Befehlslisten nicht zusammen. Fügen Sie die Schritte der Vorlage ausdrücklich wieder hinzu:

test:
  extends: .crunu
  before_script:
    - !reference [.crunu, before_script]
    - npm ci
  script:
    - crunu run --env web-app/staging -- npm test

Was geprüft wird

• Die Prüfsumme des Installers wird verglichen, bevor er läuft. Stimmt sie nicht, bricht der Job ab, und crunu wird nicht installiert.
• Der Installer prüft die Prüfsumme des Binarys und führt es einmal aus, bevor er es an seinen Platz legt.
• Fehlerhafte Werte, etwa eine fehlende Prüfsumme oder eine Adresse, die nicht https:// ist, werden abgelehnt, bevor irgendetwas heruntergeladen wird.

Runner und Prüfsummen

crunu läuft unter Linux und macOS, auf amd64 und arm64. Einen Build für Windows gibt es nicht. Die Prüfsumme im Block „CI setup“ gilt für Linux amd64; für Runner mit arm64 setzen Sie Prüfsummen pro Plattform aus der manifest.json des Releases.

Widerrufen

Öffnen Sie das Token in Crunu und wählen Sie Revoke. Seine nächste Anmeldung wird abgelehnt, und ein bereits laufender Job läuft mit dem zu Ende, was er erhalten hat. Falls das Token geleakt sein könnte, rotieren Sie auch 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
• GitLab CI in der Dokumentation
• Ein Token per OIDC binden
• Service-Tokens