Permisos de los ejecutores y de los tokens

El token que el CI entrega a un flujo tiene permisos configurables: leer el contenido, escribir, publicar paquetes, pedir identidad para entrar en la nube. La práctica recomendada por la documentación de los CI habituales es fijar por defecto solo lectura y subir los permisos únicamente en los trabajos que los necesitan, uno por uno. Un flujo de pruebas no necesita escribir en el repositorio; el que publica una imagen, sí, y solo el trabajo que publica.

Lo contrario, un permiso amplio para todo el flujo «porque así funciona a la primera», es el fallo más repetido: si algo dentro del flujo se desvía, hereda esos permisos.

La tabla de flujos tiene las columnas que, juntas, dicen si un flujo es un riesgo: quién lo dispara, qué permisos trae y dónde corre. Dos flujos tienen escritura total; uno es nocturno, programado, sin entrada de nadie de fuera. El otro puede ser iniciado por propuestas que vienen de cualquier bifurcación. Mismo permiso, riesgo muy distinto: lo que cuenta es quién controla lo que el flujo ejecuta.

Consulta la tabla de flujos y cruza las dos columnas.

Un ejecutor propio que no se limpia entre trabajos acumula lo que cada trabajo deja: archivos, credenciales en caché, variables. Si lo comparten varios repositorios, un trabajo del repositorio menos cuidado puede dejar algo que lee el trabajo de despliegue de otro. El tamaño del problema se mide con cuántos repositorios lo usan.

Mira en qué ejecutor corre el flujo de despliegue a producción y cuántos repositorios lo comparten.

Los tokens personales y de servicio son credenciales de larga vida: se crean para una prueba y se quedan. La señal de riesgo es la suma de tres cosas: no caducan, tienen un alcance amplio y llevan meses sin usarse. Una credencial así no la echa de menos nadie, y precisamente por eso nadie notaría que la usa otra persona. Fecha de la consulta: 4 de octubre de 2026.

Con la tabla de tokens delante, aplica el criterio: sin caducidad, sin uso en más de seis meses.

Para el token olvidado hay varias salidas y solo una es completa: revocarlo (así deja de servir ya), comprobar en el registro de auditoría si se usó desde algo que no fuera su dueño y, si la función es necesaria, reemplazarlo por un acceso de vida corta. Los CI habituales permiten que un flujo pida una identidad temporal a la nube mediante OIDC en lugar de guardar una clave larga, que es justo lo que busca el permiso id-token que ves en el flujo de despliegue.