Buildkite elimina los tokens persistentes de GitHub en agentes propios

El secreto que se queda a vivir en el runner

En un homelab es muy fácil resolver el acceso privado a GitHub con un PAT o una clave SSH y dejarlo montado en una VM, un contenedor o un pod. Funciona hasta que toca rotar la credencial, reconstruir una imagen o averiguar qué máquinas siguen teniendo acceso a qué repositorios. El problema no es Git, sino que el secreto tiene una vida mucho más larga que el trabajo de CI que lo necesita.

Buildkite permite ahora que los agentes autoalojados obtengan credenciales temporales de una GitHub App para hacer el checkout. El token se solicita para el trabajo en ejecución y tiene acceso de solo lectura al contenido de un repositorio concreto. Así, el runner de Laravel no necesita llevar un PAT en variables, una clave privada en ~/.ssh ni una clave privada de GitHub App instalada localmente. (buildkite.com)

Lo que cambiaría en una cola para Laravel

La función se activa por cola, no de forma global para todos los agentes de la organización. Esto permite crear una cola dedicada, por ejemplo laravel-ci, probar ahí un pipeline y mantener el resto de runners con su método actual mientras se revisan hooks, submódulos y scripts auxiliares. El requisito básico es usar Buildkite Agent 3.63.1 o posterior y tener instalada la integración de GitHub App con acceso completo a los repositorios necesarios. (buildkite.com)

Para GitHub.com, un pipeline que todavía use una URL SSH del repositorio puede seguir funcionando: Buildkite adapta el checkout a HTTPS. En GitHub Enterprise Server no ocurre esa conversión automática, así que la URL del repositorio en el pipeline debe ser HTTPS. Es un detalle pequeño, pero conviene comprobarlo antes de retirar claves de los runners. (buildkite.com)

Primero inventario, después cambio

Antes de activar nada, yo guardaría la configuración Git del usuario que ejecuta el agente en cada entorno reutilizado. El agente instala un credential helper en la configuración global y añade una regla para convertir las URL SSH de GitHub.com a HTTPS. Esos cambios no desaparecen al terminar el job, así que forman parte de la migración y también del plan de reversión. (buildkite.com)

git config --global --get-all credential.helper
git config --global --get-all credential.useHttpPath
git config --global --get-all url.https://github.com/.insteadOf

Si ese agente vive en una VM de Proxmox, un contenedor Docker persistente o un nodo de Kubernetes que reutiliza su directorio home, documentaría también cualquier hook de checkout y helper de credenciales propio. No basta con habilitar la opción y borrar la clave SSH. Hay que saber qué configuración previa queda sustituida y cómo restaurarla si el primer build falla.

Configurarlo como infraestructura

La opción también se puede gestionar por API REST, GraphQL o Terraform. En REST el campo es use_github_app_token; en GraphQL se llama useGithubAppToken; y en Terraform se configura como use_github_app_token = true dentro del recurso buildkite_cluster_queue. Para Terraform hace falta el proveedor de Buildkite en versión 1.43.0 o posterior. (buildkite.com)

resource "buildkite_cluster_queue" "laravel_ci" {
  # Resto de la configuración de la cola
  use_github_app_token = true
}

Para mí, el valor está en evitar excepciones manuales. La definición de la cola puede viajar con el resto de la infraestructura, y un runner nuevo no necesita recibir una credencial de repositorio durante el aprovisionamiento. La configuración del acceso deja de depender de que alguien recuerde copiar un secreto a una imagen base.

La letra pequeña que no conviene ignorar

Esto resuelve el checkout, no convierte al job en un cliente autenticado genérico de GitHub. El token tiene permiso contents:read, no sirve para hacer git push ni debe usarse como token para llamadas API desde scripts de Laravel, despliegues o automatizaciones. Si un paso necesita publicar tags, crear releases o comentar una pull request, necesitará otro mecanismo de autenticación con permisos ajustados a esa tarea. (buildkite.com)

Los tokens caducan una hora después de que GitHub los emite, y Buildkite puede reutilizar un token cifrado durante 50 minutos. Un job terminado tampoco revoca de inmediato un token que ya se hubiera emitido, por lo que sigue siendo un secreto que no debe aparecer en logs, URLs remotas ni artefactos. Reducir su duración no elimina la obligación de tratarlo bien. (buildkite.com)

También hay límites al clonar repositorios adicionales. Deben pertenecer a la misma cuenta de GitHub que el repositorio del pipeline y la instalación de la GitHub App debe tener acceso a ellos; además, los clones extra y los submódulos deben usar HTTPS. Si el helper gestionado no logra pedir un token, no vuelve silenciosamente a una clave SSH anterior. (buildkite.com)

Por último, una cola distinta no aísla por sí sola dos agentes que comparten usuario y directorio home. Si hay cargas con requisitos incompatibles, usaría usuarios de sistema separados o entornos realmente aislados. Es la diferencia entre habilitar una opción de CI y hacer una migración de credenciales que se pueda operar sin sorpresas. (buildkite.com)

Fuente de Buildkite

Documentación oficial de acceso al código en agentes autoalojados