Sekrety w GitHub Actions z Crunu i OIDC

Co Crunu robi w GitHub Actions

Krok workflow uruchamia twoje polecenie przez crunu run. Agent crunu loguje się tokenem usługowym, sprawdza podpisy wszystkiego, co wysyła serwer, odszyfrowuje zmienne we własnej pamięci i uruchamia z nimi polecenie. Nic nie jest zapisywane na dysku.

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

Token dostaje tylko środowiska, do których dasz mu dostęp. Z powiązaniem CI (OIDC) potrzebuje też świeżego tokenu GitHuba dla repozytorium, gałęzi i środowiska wdrożenia, które ustawisz, więc wyciekły CRUNU_TOKEN nie zaloguje się sam. crunu sam prosi o ten token GitHuba, a serwer odrzuca token, który był już użyty.

Konfiguracja

1. W Crunu otwórz Service tokens i wybierz New service token. Nadaj mu nazwę, na przykład github-actions-web-app, przyznaj web-app / staging i zostaw domyślną dzierżawę 30 dni. Token przestaje działać, jeśli żadne uruchomienie nie użyje go dłużej niż przez czas dzierżawy, a każde uruchomienie ją przedłuża.
2. Token jest pokazywany tylko raz. Od razu zapisz go jako sekret repozytorium CRUNU_TOKEN.
3. Skopiuj wartości z bloku CI setup na stronie tokenu do zmiennych repozytorium: CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 i CRUNU_BINARY_SHA256. Pochodzą z podpisanego manifestu wydania. W chmurze CRUNU_SERVER to https://app.crunu.com.
4. Opcjonalnie dodaj powiązanie CI (OIDC) na stronie tokenu. Wybierz dostawcę GitHub i ustaw repository, ref oraz, dla tokenu production, environment.

Przykładowy workflow

To zadanie instaluje przypiętą wersję crunu, sprawdza SHA-256 instalatora przed jego uruchomieniem i uruchamia testy ze zmiennymi 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

Dla tokenu production powiązanie CI (OIDC) może wymagać:

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

Audience to adres twojego serwera Crunu. crunu prosi GitHub o token z tym audience, dlatego zadanie potrzebuje id-token: write.

Akcja setup-crunu

Te same kroki instalacji są też dostępne jako mała akcja złożona, setup-crunu. Nie jest opublikowana w GitHub Marketplace. Trzymaj kopię jej dwóch plików w .github/actions/setup-crunu/ swojego repozytorium, żeby kod, który dotyka sekretów potoku, przechodził ten sam przegląd co reszta twojego kodu. Jeśli zamiast tego publikujesz ją jako osobne repozytorium, przypnij ją do pełnego SHA commita, a nie do tagu.

      - 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

Akcja nie łączy się z serwerem Crunu. Tylko instaluje crunu i dodaje go do PATH dla kolejnych kroków.

Token poza zasięgiem

• Ustaw CRUNU_TOKEN w env tylko tego jednego kroku, który uruchamia crunu. Zmienne na poziomie zadania i workflow trafiają do każdego kroku.
• Uruchamiaj crunu przez exec. Powłoka kroku zostaje wtedy zastąpiona przez crunu, a token nie zostaje w procesie, który twoje polecenie mogłoby odczytać.
• Polecenie uruchomione przez crunu run nigdy nie dostaje własnych danych logowania crunu, takich jak CRUNU_TOKEN czy CRUNU_OIDC_TOKEN.

Runnery i sumy kontrolne

crunu działa na runnerach z Linuksem i macOS, na amd64 i arm64, także na runnerach własnych (self-hosted). Runnery z Windows nie są obsługiwane. Suma kontrolna w bloku CI setup dotyczy Linuksa na amd64. Dla runnerów arm64 lub macOS ustaw sumy kontrolne dla poszczególnych platform z pliku manifest.json wydania, na przykład amd64=… i darwin-arm64=….

Production bez CI

Konfiguracja zalecana przez Crunu trzyma wartości production poza potokiem. Serwer produkcyjny uruchamia agenta crunu i sam pobiera swoje środowisko, a workflow tylko dostarcza kod i restartuje usługę. Zobacz systemd.

Unieważnianie tokenu

Otwórz token i wybierz Revoke. Jego następne logowanie zostanie odrzucone, a krok, który już trwa, kończy się z tym, co otrzymał. Jeśli token mógł wyciec, unieważnij go, wymień klucze środowisk, do których miał dostęp, i wygeneruj ponownie zapisane w nich wartości u ich dostawców.

Zobacz także

• CI/CD w Crunu
• GitHub Actions w dokumentacji
• Powiązanie tokenu przez OIDC
• Tokeny usługowe