Variabelen voor GitLab CI uit Crunu, gebonden met id_tokens

Wat Crunu doet in GitLab CI

Een job voert je opdracht uit via crunu run. De agent crunu logt in met een servicetoken, controleert handtekeningen, ontsleutelt de variabelen in het geheugen en start de opdracht ermee. Er wordt niets naar schijf geschreven.

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

Het token krijgt alleen de omgevingen die je toekent. Met een CI-binding (OIDC) geeft GitLab de job een token met je Crunu-server als audience, en het Crunu-token werkt alleen samen daarmee, voor het projectpad, de ref en de omgeving die je instelt. crunu leest het GitLab-token zelf uit CRUNU_ID_TOKEN.

Instellen

1. Open in Crunu Service tokens en kies New service token. Ken de omgevingen toe die de job nodig heeft. Het token wordt maar één keer getoond.
2. Open in GitLab Settings → CI/CD → Variables en voeg CRUNU_TOKEN toe als gemaskeerde, beschermde variabele.
3. Voeg CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 en CRUNU_BINARY_SHA256 toe met de waarden uit het blok CI setup op de pagina van het token. In de cloud is CRUNU_SERVER gelijk aan https://app.crunu.com.
4. Optioneel: voeg op de pagina van het token een CI-binding (OIDC) toe. Kies de provider GitLab en stel project_path, ref, ref_type en, voor een token voor production, environment in.

Voorbeeldjob

De image van de job heeft sh en curl of wget nodig. De images node, python en alpine hebben die.

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

Voor een token voor production kan de CI-binding (OIDC) dit vereisen:

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

De jobsjablonen .crunu

De installatiestappen bestaan ook als sjabloonbestand met twee verborgen jobs. Je jobs nemen ze over met extends:

• .crunu installeert een vastgezette versie van crunu in before_script, controleert de SHA-256 van het installatiescript en van de binary, en toont crunu version;
• .crunu-oidc doet hetzelfde en voegt id_tokens toe, voor tokens met een CI-binding.

Bewaar een kopie van het sjabloon in je repository, zodat wijzigingen eraan samen met je code worden gereviewd. Neem je het in plaats daarvan op uit een ander GitLab-project, zet ref dan vast op een commit, niet op een 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

De eigen before_script van een job vervangt die van het sjabloon, omdat extends lijsten met opdrachten niet samenvoegt. Voeg de stappen van het sjabloon expliciet weer toe:

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

Wat er wordt gecontroleerd

• De checksum van het installatiescript wordt vergeleken voordat het draait. Komt die niet overeen, dan stopt de job en wordt crunu niet geïnstalleerd.
• Het installatiescript controleert de checksum van de binary en voert die één keer uit voordat die op zijn plek komt.
• Ongeldige waarden, zoals een ontbrekende checksum of een adres dat niet met https:// begint, worden geweigerd voordat er iets wordt gedownload.

Runners en checksums

crunu draait op Linux en macOS, op amd64 en arm64. Er is geen build voor Windows. De checksum in het blok CI setup is voor Linux amd64; stel voor runners met arm64 checksums per platform in uit de manifest.json van de release.

Intrekken

Open het token in Crunu en kies Revoke. Het volgende inloggen ervan wordt geweigerd, en een job die al draait, maakt af met wat hij heeft ontvangen. Kan het token zijn gelekt, roteer dan ook de sleutels van de omgevingen die het kreeg, en geef de waarden daarin opnieuw uit bij hun providers.

Verwant

• CI/CD in Crunu
• GitLab CI in de documentatie
• Een token binden met OIDC
• Servicetokens