La compuerta de aprobación y el ejecutor

El pipeline de un merge request ejecuta código que nadie revisó todavía, así que en Airframe nunca se le confían credenciales de la nube. Dos partes de la plataforma hacen el trabajo de confianza en su lugar. La compuerta de aprobación decide si un merge request fue aprobado por las personas correctas, y el ejecutor es el único lugar donde los planes, las compilaciones de imágenes y las vistas previas de un merge request se ejecutan con identidades reales. Esta página explica qué hace cada uno, y en qué orden.

Por qué el pipeline de un merge request no es de confianza

Cualquiera que pueda subir una rama puede cambiar el archivo de pipeline en esa rama. Si ese pipeline pudiera obtener la identidad de un producto, un solo push sin revisar podría leer o cambiar los proyectos en la nube del producto.

Por eso, el pipeline propio de un merge request no recibe ninguna identidad. Se ejecuta en el runner sin confianza de la plataforma, una máquina propia que no tiene ninguna credencial que un trabajo pueda usar y no puede llegar al servidor de metadatos de la nube ni a las redes de la plataforma, y hace solo lo que no necesita credenciales: el formato, la validación de Terraform sin backend, el paquete de políticas sobre el código, las verificaciones del catálogo, la compilación y las pruebas de la aplicación. La mayor parte de esto también lo ejecuta airframe validate en una laptop.

Todo lo que necesita ver la nube real espera hasta que una persona responsable del código haya aprobado el cambio.

La compuerta de aprobación

La compuerta de aprobación es un servicio pequeño en el proyecto de integración continua de la plataforma. Responde tres tipos de preguntas.

¿Este merge request fue aprobado por sus responsables actuales? Cuando alguien aprueba un merge request, GitLab llama a la compuerta. La compuerta lee el modelo de responsables desde la rama main protegida del catálogo, nunca desde el propio cambio, y revisa las aprobaciones en el último commit del merge request. La aprobación del autor y las de quienes hicieron commits nunca cuentan. Si las personas correctas aprobaron, la compuerta agrega su propia aprobación, vinculada a ese commit exacto, e inicia el ejecutor. Un merge request no se puede integrar sin la aprobación de la compuerta: una política de aprobación de GitLab en el repositorio security-policies la exige en cada repositorio que nombra, que hoy son todos los repositorios menos el propio security-policies.

Un repositorio nuevo, como el de un producto creado después del último cambio de esa lista, no queda cubierto hasta que dos merge requests lo agregan: uno a la lista de repositorios exigidos de la compuerta en control-plane, y después uno al alcance de la política en security-policies. Mientras tanto, solo necesita la aprobación de una persona con nombre que no escribió el cambio.

¿Puede ejecutarse este pipeline? Todo pipeline del grupo, salvo los de security-policies, empieza con un trabajo, gate:integrity, que el repositorio no puede quitar. Envía a la compuerta el token firmado del trabajo, a una dirección escrita en el propio trabajo: ninguna variable de un proyecto o de un grupo puede cambiarla, y una dirección vacía hace fallar el trabajo como una compuerta inalcanzable. En una rama main protegida, la compuerta deja continuar el pipeline solo para el último commit de un merge request integrado, o para el primer commit del repositorio de un producto generado desde el catálogo. También hace fallar un pipeline que usa una versión de la plataforma revocada.

¿Cuánto cuesta este cambio? Para el merge request de un producto, la compuerta suma el costo mensual de los planes con precio del ejecutor y define una verificación de estado llamada “Airframe cost”. Falla cuando el total, o cualquier raíz por sí sola, supera el presupuesto del producto en el catálogo, y GitLab mantiene cerrado el merge hasta que pase.

El ejecutor

El ejecutor es un pipeline del repositorio control-plane que se ejecuta en el runner de confianza de la plataforma, una máquina dentro de la red propia de la plataforma. Solo la compuerta puede iniciarlo, con un token de disparo que solo ella tiene.

Cuando empieza una ejecución, el ejecutor vuelve a verificar todo antes de tener cualquier credencial: que el último commit del merge request siga siendo el aprobado, que sus aprobaciones sigan satisfechas, y que la compuerta siga autorizando ese commit. Después, para un producto:

planifica cada raíz de Terraform del producto con la identidad de plan del producto, que puede leer y no cambia nada, y publica los planes en el merge request;
pone precio a los planes con Infracost, una herramienta que estima el precio mensual de un plan de Terraform, y le informa el costo a la compuerta;
hace que el constructor de confianza construya las imágenes de contenedor del commit;
despliega la vista previa del merge request con la identidad de apply de no producción.

El ejecutor puede usar la identidad de plan y la identidad de apply de no producción de cada producto, y ninguna de producción. Nada de lo que hace antes de un merge puede cambiar producción.

Después del merge

Una vez integrado el merge request, el pipeline de la rama main protegida del repositorio toma el control, en el runner de confianza, con la identidad propia de cada raíz:

build:request le pide a la compuerta las imágenes que el ejecutor construyó al aprobarse el cambio.
plan:<root>, un trabajo por raíz, la planifica contra la infraestructura real.
policy:<root> ejecuta el paquete de políticas sobre ese plan, y el apply necesita que pase.
apply:<root> aplica el plan. No producción se aplica por su cuenta; para producción, primero va el sandbox y después producción con la imagen promovida.

Si alguien integra el merge request antes de que termine la ejecución del ejecutor, la verificación del commit en esa ejecución falla, porque la compuerta ya no autoriza ese commit para una ejecución de merge request. No se salta nada: build:request en main no encuentra una compilación terminada, le pide una a la compuerta y la espera. Esto ocurrió el 2026-09-30 con un cambio en este sitio web, y el despliegue simplemente tardó unos minutos más.

Qué protege esto

Un atacante que solo puede subir una rama obtiene un pipeline sin credenciales. Uno que puede aprobar su propio cambio no llega a ningún lado, porque la compuerta no cuenta al autor. Un cambio que pasó la revisión y después recibió un commit nuevo pierde la aprobación de la compuerta, porque esa aprobación está vinculada al commit que revisó. Y como producción solo se aplica desde la rama main protegida, con una identidad que ningún merge request puede obtener, el único camino a producción es un cambio revisado e integrado.

Dónde está

En el repositorio control-plane: