Entrevista de Backend: ¿Cómo protegerías un flujo de trabajo reutilizable de GitHub Actions?

Consigna y caso de uso

Tu equipo extrae los pasos de compilación, prueba y publicación en flujos de trabajo reutilizables que se comparten entre varios repositorios. Diseña el contrato para entradas, salidas, secretos, permisos de GITHUB_TOKEN y referencias de versión entre los flujos de trabajo que llaman y los que son llamados. Explica cómo previenes la escalada de privilegios, la desviación de la cadena de suministro y la confusión de contexto.

Qué evalúa el entrevistador

• Si comprendes que los flujos de trabajo reutilizables se llaman a nivel de trabajo (job), no como pasos ordinarios.
• Si puedes explicar que los permisos de GITHUB_TOKEN del llamador solo pueden ser reducidos por el flujo de trabajo llamado, no elevados.
• Si minimizas la exposición de secrets, variables de entorno y el contexto github.
• Si manejas los límites de anidamiento, límites de llamadas, anclaje de referencias y políticas de la organización.

Preguntas para aclarar antes de responder

• ¿La reutilización es entre repositorios, entre organizaciones o dentro de un solo repositorio, y qué políticas de visibilidad aplican?
• ¿El flujo de trabajo llamado solo compila artefactos, o puede desplegar, publicar o escribir de vuelta en un repositorio?
• ¿Los secretos se pasan individualmente, se heredan a nivel de organización o están protegidos por una regla de entorno?
• ¿Las actualizaciones deben seguir una rama, una etiqueta de versión o una referencia de commit inmutable?

Estructura de respuesta de 30 segundos

Definiría una interfaz estrecha: workflow_call declara entradas tipadas, secretos individuales y salidas requeridas; el trabajo llamador establece los permisos mínimos de permissions, y el flujo de trabajo llamado los restringe aún más. Los flujos de trabajo de publicación y de compilación se mantienen separados, mientras que los entornos protegidos controlan los despliegues sensibles. Las referencias utilizan commits revisados o etiquetas controladas, y las políticas de la organización limitan las acciones y los flujos de trabajo reutilizables permitidos. Por último, los registros de auditoría, el comportamiento de reejecución y las pruebas de regresión de permisos verifican el contrato.

Análisis detallado paso a paso

1. El límite del flujo de trabajo reutilizable

Un flujo de trabajo reutilizable se activa mediante workflow_call, y el llamador utiliza uses en un trabajo. El trabajo que llama está limitado a claves documentadas como with, secrets, permissions, strategy y needs; no es un paso ordinario donde se puedan inyectar comandos arbitrarios.

2. Entradas, salidas y restricciones de tipo

Declara las entradas obligatorias, los valores predeterminados y los tipos en el flujo de trabajo llamado para que un contrato de llamador no válido falle durante el análisis sintáctico. Expón solo resúmenes (digests) de artefactos, versiones o estados de resultados necesarios para la automatización del release; nunca devuelvas tokens, registros completos ni rutas internas.

3. Pasar secretos individualmente

Prefiere un mapa explícito de secrets que pase solo la credencial necesaria para una acción de despliegue determinada. secrets: inherit pasa todos los secretos disponibles para el llamador y puede ajustarse a un caso estrictamente delimitado dentro de la misma organización, pero expande la superficie de auditoría y de fugas, por lo que debe evitarse a través de límites de confianza.

4. Reducir los permisos de GITHUB_TOKEN

El trabajo llamador debe declarar permissions explícitamente, como acceso de solo lectura al código fuente más escritura de artefactos. GitHub documenta que los permisos heredados por el flujo de trabajo llamado pueden mantenerse iguales o volverse más restrictivos, nunca más permisivos. Por lo tanto, las acciones con altos privilegios requieren una concesión explícita en el llamador y una justificación de revisión registrada.

5. Pertenencia del contexto github

El contexto github dentro de un flujo de trabajo llamado está asociado con el flujo de trabajo llamador. No asumas que la rama, el evento o los permisos del repositorio llamado reemplazan la información del llamador. Si se requiere el repositorio fuente, el commit o la identidad del actor, pásalo explícitamente y ocúltalo en los registros donde sea apropiado.

6. Referencias y desviación de la cadena de suministro

Los flujos de trabajo pueden hacer referencia a ramas, etiquetas o commits. Las ramas se mueven y las etiquetas se pueden redirigir; las rutas de producción deben usar commits inmutables revisados o políticas de la organización que restrinjan las referencias aceptables. La política de GitHub Actions también puede requerir hashes SHA de commit completos para las acciones y limitar las fuentes permitidas.

7. Anidamiento, matrices y concurrencia

Los flujos de trabajo reutilizables anidados pueden alcanzar hasta diez niveles, y un único archivo de flujo de trabajo puede conectar como máximo cincuenta flujos de trabajo reutilizables únicos. Una matriz puede llamar a un flujo de trabajo reutilizable, pero cada combinación necesita límites de recursos, un grupo de concurrencia y una política de cancelación para evitar publicaciones duplicadas o cancelaciones mutuas.

8. Auditoría, reejecuciones y reversión

Registra el repositorio llamador, el commit, el digest de entrada, la declaración de permisos y el digest del artefacto. Reejecutar todos los trabajos puede resolver una referencia nuevamente, mientras que reejecutar trabajos fallidos puede usar el commit del primer intento, por lo que el registro de auditoría debe contener la versión realmente resuelta. La reversión cambia a una referencia verificada y revoca la autorización del entorno protegido.

Compensaciones y límites

• inherit reduce la configuración pero hace que el límite del secreto sea implícito; las plataformas entre organizaciones o multiinquilino deben mapear los secretos de forma explícita.
• Anclar commits mejora la reproducibilidad, pero las actualizaciones requieren modificaciones automatizadas, revisión y una ventana de reversión.
• Empaquetar el despliegue en un flujo de trabajo genérico elimina la duplicación pero puede ocultar la protección del entorno; el despliegue a producción debe mantener visibles los límites de aprobación.
• Los permisos de token autorizan llamadas a la API; no hacen que los archivos del runner, las redes o las acciones de terceros sean confiables. El código no confiable aún requiere aislamiento.

Plan de implementación y evidencia

1. Escribe el contrato de entradas, salidas y secretos individuales de workflow_call, rechazando campos no declarados.
2. Genera una matriz de permisos para cada trabajo llamador y verifica que el flujo de trabajo llamado no pueda elevar GITHUB_TOKEN.
3. Ancla las referencias de producción a commits revisados, configura una lista de permitidos en la organización y verifica la política de SHA.
4. Ejecuta simulacros de pull requests, entre repositorios, anidados y de reejecución con secretos simulados y un repositorio restringido.
5. Revisa la implementación frente a la documentación de GitHub sobre flujos de trabajo reutilizables, sintaxis de flujos de trabajo y configuración de Actions.

Errores comunes y preguntas de seguimiento

Error 1: Tratar un flujo de trabajo reutilizable como un paso de acción

Se llama a nivel de trabajo con un conjunto diferente de campos y contextos. Copiar directamente la sintaxis de pasos puede fallar en el análisis o generar suposiciones de permisos incorrectas.

Error 2: Usar secrets.inherit por defecto

La herencia le otorga al flujo de trabajo llamado todos los secretos a los que puede acceder el llamador. A menos que el límite de confianza y el alcance de la organización sean explícitos, pasa los secretos individualmente.

Error 3: Establecer permisos altos solo en el flujo de trabajo llamado

El flujo de trabajo llamado no puede elevar el token del llamador. Los privilegios altos deben declararse en el trabajo llamador y justificarse mediante revisión y auditoría.

Pregunta de seguimiento: ¿Por qué las referencias por etiqueta siguen siendo riesgosas?

Las etiquetas pueden moverse, por lo que una reejecución o una ejecución posterior puede resolver un commit diferente. La producción debe anclar un commit revisado o restringir las referencias permitidas mediante políticas de la organización.

Pregunta de seguimiento: ¿Cómo demuestras que no se filtran secretos?

Ejecuta la ruta completa con secretos simulados y el mínimo privilegio, inspecciona registros, salidas, artefactos y rutas de error, y audita el acceso de lectura de inherit, variables de entorno y acciones de terceros.