Segredos no GitHub Actions com o Crunu e OIDC

O que o Crunu faz no GitHub Actions

Um passo do workflow executa o seu comando por meio do crunu run. O agente crunu entra com um token de serviço, confere as assinaturas de tudo o que o servidor envia, descriptografa as variáveis na própria memória e inicia o comando com elas. Nada é gravado no disco.

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

O token recebe só os ambientes que você concede a ele. Com um vínculo de CI (OIDC), ele também precisa de um token novo do GitHub para o repositório, o branch e o ambiente de deploy que você definir, então um CRUNU_TOKEN vazado não consegue entrar sozinho. O próprio crunu pede esse token ao GitHub, e o servidor rejeita um que já tenha sido usado.

Configuração

1. No Crunu, abra Service tokens e escolha New service token. Dê um nome como github-actions-web-app, conceda web-app / staging e mantenha a concessão padrão de 30 dias. O token deixa de funcionar se nenhuma execução o usar por mais tempo que a concessão, e cada execução a prolonga.
2. O token só é mostrado uma vez. Guarde-o na mesma hora como o segredo de repositório CRUNU_TOKEN.
3. Copie os valores do bloco CI setup da página do token para variáveis de repositório: CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 e CRUNU_BINARY_SHA256. Eles vêm do manifesto de release assinado. Na nuvem, CRUNU_SERVER é https://app.crunu.com.
4. Opcional: adicione um vínculo de CI (OIDC) na página do token. Escolha o provedor GitHub e defina repository, ref e, para um token de production, environment.

Exemplo de workflow

Este job instala uma versão fixa do crunu, confere o SHA-256 do instalador antes de executá-lo e roda os testes com as variáveis do 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

Para um token de production, o vínculo de CI (OIDC) pode exigir:

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

O audience é o endereço do seu servidor do Crunu. O crunu pede ao GitHub um token com esse audience, e é por isso que o job precisa de id-token: write.

A action setup-crunu

Os mesmos passos de instalação também existem como uma pequena action composta, a setup-crunu. Ela não está publicada no GitHub Marketplace. Mantenha uma cópia dos dois arquivos dela em .github/actions/setup-crunu/ no seu repositório, para que o código que lida com os segredos do seu pipeline passe pela mesma revisão que o resto do seu código. Se, em vez disso, você a publicar como um repositório separado, fixe-a num SHA de commit completo, não numa 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

A action não se comunica com o servidor do Crunu. Ela só instala o crunu e o adiciona ao PATH para os passos seguintes.

Mantenha o token fora de alcance

• Defina o CRUNU_TOKEN no env do único passo que executa o crunu. Variáveis no nível do job e do workflow chegam a todos os passos.
• Inicie o crunu com exec. Assim, o shell do passo é substituído pelo crunu, e o token não fica num processo que o seu comando consiga ler.
• O comando sob o crunu run nunca recebe as credenciais do próprio crunu, como CRUNU_TOKEN ou CRUNU_OIDC_TOKEN.

Runners e checksums

O crunu roda em runners Linux e macOS, em amd64 e arm64, inclusive em runners auto-hospedados. Runners Windows não são compatíveis. O checksum do bloco CI setup é para Linux amd64. Para runners arm64 ou macOS, defina checksums por plataforma a partir do manifest.json do release, por exemplo amd64=… e darwin-arm64=….

Production sem CI

A configuração que o Crunu recomenda mantém os valores de production fora do pipeline. O servidor de production roda o agente crunu e busca o próprio ambiente, e o workflow só entrega o código e reinicia o serviço. Veja systemd.

Revogação

Abra o token e escolha Revoke. O próximo login dele é recusado, e um passo que já está rodando termina com o que recebeu. Se o token pode ter vazado, revogue-o, rotacione as chaves dos ambientes que ele recebeu e reemita os valores contidos neles nos respectivos provedores.

Veja também

• CI/CD no Crunu
• GitHub Actions na documentação
• Vincule um token com OIDC
• Tokens de serviço