Limitar los permisos de la entrega

Quien revisa una receta no necesita la llave de la caja registradora. Dar acceso a todo puede parecer cómodo, pero también permite que un error alcance lugares que no tenían relación con la tarea.

En una automatización, cada trabajo utiliza una identidad con permisos. La pregunta útil es concreta: ¿qué necesita leer o modificar para cumplir su función? Después conviene revisar durante cuánto tiempo necesita ese acceso.

Una tarea, un acceso justificado

Para comprobar la regla de nuestro pedido basta con obtener el código y ejecutar las pruebas en un entorno controlado. Ese trabajo no necesita publicar en producción ni consultar datos de clientes. Un ejemplo de permiso limitado para el token del repositorio en GitHub Actions es:

permissions:
  contents: read

Esta declaración limita permisos del token del flujo; no describe por completo todos los accesos del equipo ejecutor. Todavía hay que revisar sus credenciales, conexiones y archivos. Un permiso reducido en YAML no compensa un entorno que ya tiene accesos excesivos.

El código que ejecutamos también importa

Un cambio propuesto puede modificar las pruebas o los scripts. Si se ejecuta con credenciales sensibles, esas instrucciones podrían utilizarlas. Por eso se evalúan el origen del código y el contexto del evento antes de otorgar accesos.

Las acciones de terceros también ejecutan código. En GitHub, fijarlas a un identificador completo de commit ayuda a utilizar una revisión concreta; una etiqueta puede cambiar de destino. Esto no elimina la necesidad de revisar al proveedor y mantener las versiones. Identidad estable y confianza son preguntas relacionadas, pero distintas.

En nuestro caso conceptual, el trabajo que prepara un paquete y el que lo activa pueden tener accesos diferentes. El segundo recibe únicamente los que necesita para ese ambiente, bajo las condiciones de autorización establecidas.