Secretos de GitHub Actions con Crunu y OIDC

Qué hace Crunu en GitHub Actions

Un paso del workflow ejecuta tu comando mediante crunu run. El agente crunu inicia sesión con un token de servicio, comprueba las firmas de todo lo que envía el servidor, descifra las variables en su propia memoria e inicia el comando con ellas. No se escribe nada en disco.

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

El token recibe solo los entornos que le concedes. Con una vinculación de CI (OIDC), además necesita un token de GitHub reciente para el repositorio, la rama y el entorno de despliegue que fijes, así que un CRUNU_TOKEN filtrado no puede iniciar sesión por sí solo. crunu pide ese token de GitHub por su cuenta, y el servidor rechaza uno que ya se haya usado.

Configuración

1. En Crunu, abre Service tokens y elige New service token. Dale un nombre como github-actions-web-app, concede web-app / staging y deja la concesión por defecto de 30 días. El token deja de funcionar si ninguna ejecución lo usa durante más tiempo que la concesión, y cada ejecución la prolonga.
2. El token se muestra una sola vez. Guárdalo enseguida como secreto del repositorio CRUNU_TOKEN.
3. Copia los valores del bloque CI setup de la página del token en variables del repositorio: CRUNU_SERVER, CRUNU_VERSION, CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256 y CRUNU_BINARY_SHA256. Proceden del manifiesto firmado de la versión publicada. En la nube, CRUNU_SERVER es https://app.crunu.com.
4. Opcional: añade una vinculación de CI (OIDC) en la página del token. Elige el proveedor GitHub y fija repository, ref y, para un token de production, environment.

Workflow de ejemplo

Este trabajo instala una versión fijada de crunu, comprueba el SHA-256 del instalador antes de ejecutarlo y ejecuta las pruebas con las variables de 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 un token de production, la vinculación de CI (OIDC) podría exigir:

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

La audiencia es la dirección de tu servidor de Crunu. crunu pide a GitHub un token con esa audiencia, y por eso el trabajo necesita id-token: write.

La acción setup-crunu

Los mismos pasos de instalación vienen también como una pequeña acción compuesta, setup-crunu. No está publicada en GitHub Marketplace. Guarda una copia de sus dos archivos en .github/actions/setup-crunu/ de tu repositorio, para que el código que toca los secretos de tu pipeline pase por la misma revisión que el resto de tu código. Si prefieres publicarla como un repositorio aparte, fíjala a un SHA de commit completo, no a una etiqueta.

      - 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

La acción no contacta con el servidor de Crunu. Solo instala crunu y lo añade al PATH para los pasos siguientes.

Mantén el token fuera de alcance

• Define CRUNU_TOKEN en el env del único paso que ejecuta crunu. Las variables a nivel de trabajo y de workflow llegan a todos los pasos.
• Inicia crunu con exec. Así el shell del paso se sustituye por crunu, y el token no queda en un proceso que tu comando pueda leer.
• El comando que se ejecuta bajo crunu run nunca recibe las credenciales propias de crunu, como CRUNU_TOKEN o CRUNU_OIDC_TOKEN.

Runners y sumas de verificación

crunu funciona en runners de Linux y macOS, en amd64 y arm64, incluidos los runners autoalojados. Los runners de Windows no son compatibles. La suma de verificación del bloque CI setup es para Linux amd64. Para runners arm64 o macOS, define sumas de verificación por plataforma a partir del manifest.json de la versión publicada, por ejemplo amd64=… y darwin-arm64=….

Production sin CI

La configuración que recomienda Crunu deja los valores de production fuera del pipeline. El servidor de production ejecuta el agente crunu y obtiene su propio entorno, y el workflow solo entrega el código y reinicia el servicio. Consulta systemd.

Revocación

Abre el token y elige Revoke. Su siguiente inicio de sesión se rechaza, y un paso que ya está en marcha termina con lo que recibió. Si el token pudo filtrarse, revócalo, rota las claves de los entornos que se le dieron y reemite los valores que contienen en sus proveedores.

Relacionado

• CI/CD en Crunu
• GitHub Actions en la documentación
• Vincular un token con OIDC
• Tokens de servicio