El token y los disparadores en GitHub Actions

El token que GitHub entrega a cada ejecución tiene permisos por alcance: leer el contenido, escribir propuestas, publicar paquetes, pedir una identidad para la nube. Se fijan con la clave permissions, a nivel de flujo o de trabajo. Si el flujo no la declara, el token hereda lo que diga el ajuste por defecto del repositorio o de la organización, que puede ser solo lectura o lectura y escritura.

La recomendación de la documentación oficial es partir de lo mínimo y subir los permisos solo en el trabajo que los necesita. Así, si algo dentro de un trabajo se desvía, el token que hereda es pequeño.

Un flujo con el evento pull_request que viene de una bifurcación corre con un token de solo lectura y sin secretos: es lo que le toca a una propuesta de un desconocido. El evento pull_request_target es distinto: corre en el contexto de la rama base, con acceso a los secretos y, según el flujo, con permisos de escritura. Está pensado para tareas como poner una etiqueta o un comentario, que no necesitan el código de quien propone.

El riesgo aparece cuando un flujo con pull_request_target descarga el código de la propuesta y lo ejecuta: entonces el código de un extraño corre con los privilegios de la rama base. La documentación oficial pide evitar este evento si no es necesario.

Abre los cinco flujos de .github/workflows y busca el que reúne las dos cosas.

Para saber cuánto puede escribir un trabajo no basta con leer el flujo: hay que mirar también el ajuste del repositorio. Un trabajo sin permissions ni en el flujo ni en él mismo recibe el permiso por defecto, y el archivo de ajustes de Mirto Pagos dice cuál es.

Cuenta los trabajos con permiso de escritura efectivo: los que lo declaran y los que lo heredan.

En el flujo que publica la imagen aparece id-token: write. Ese permiso no escribe en el repositorio: deja que el trabajo pida a GitHub un token OIDC de vida corta que un proveedor de nube puede aceptar a cambio de un acceso temporal. Es la alternativa a guardar una clave larga como secreto.

El flujo de la vista previa ejecuta el código de una propuesta externa con un secreto a mano. La corrección no es añadir una validación al script: es cambiar quién controla lo que corre. La vista previa de una propuesta ajena puede construirse con el evento pull_request, que no entrega secretos a las bifurcaciones; lo que sí necesite un secreto va en un paso posterior, ya sobre código revisado y aprobado.