Políticas como código

En Airframe, las reglas de la plataforma son código: un conjunto de reglas probadas, el paquete de políticas, revisa cada cambio en el Terraform, el archivo de pipeline y los Dockerfiles declarados de un producto antes de que se pueda integrar, y vuelve a revisar el plan antes de aplicar nada. Las personas aprueban para qué es un cambio; las reglas revisan cómo se hace. Esta página explica qué miran las reglas, qué hacen sus dos veredictos, y las brechas que todavía están abiertas.

Qué es el paquete de políticas

El paquete de políticas es un conjunto de reglas escritas en Rego, el lenguaje de Open Policy Agent, guardado en el repositorio control-plane. Una herramienta llamada Conftest las ejecuta contra un cambio. Cada regla mira una cosa y dice si está permitida, por ejemplo:

ningún recurso puede otorgarse a allUsers, lo que lo haría público;
nadie puede recibir los roles amplios owner o editor;
todo recurso con etiquetas lleva el conjunto completo de etiquetas de la plataforma, que lo vinculan a su producto para el costo y la auditoría;
todo recurso regional está en us-central1, la única región de la plataforma;
el archivo de pipeline de un producto incluye solo los componentes de pipeline propios de la plataforma, y ninguno de sus trabajos despliega;
un Dockerfile construye solo a partir de las imágenes base de la plataforma, fijadas.

Dónde se ejecuta

Las mismas reglas se ejecutan en cuatro lugares, así que quien contribuye encuentra la misma respuesta en todos:

En una laptop, con airframe validate, sin credenciales, antes de abrir un merge request.
En el pipeline del merge request, sobre el código Terraform y el archivo de pipeline, en un trabajo que el repositorio no puede quitar. Desde la versión de la plataforma 2026.10.01-1, también ejecuta las reglas de Dockerfile en cada merge request que cambia un Dockerfile listado en .airframe/images.yaml y llamado Dockerfile, Dockerfile.*, *.Dockerfile o *.dockerfile.
En las ejecuciones del ejecutor, al aprobarse un merge request.
Sobre el plan, en main, en el trabajo policy:<root> de la raíz antes de cada apply: el apply necesita que ese trabajo pase. El plan muestra los valores reales que el código solo puede dejar sin resolver, así que aquí es donde las reglas ven todo.

Las reglas de costo son la única excepción: necesitan precios, así que se ejecutan en el ejecutor y deciden la verificación de estado “Airframe cost”. La página de la compuerta de aprobación y el ejecutor lo explica.

Una validación que un producto no puede apagar

El archivo de pipeline de un producto lo cambia el equipo, así que las verificaciones importantes no viven en él. Las políticas de ejecución de pipelines de GitLab, guardadas en el repositorio security-policies, inyectan trabajos en cada pipeline:

la verificación de integridad de la compuerta de aprobación, en cada pipeline del grupo de GitLab;
la validación, incluido el paquete de políticas, y la evidencia de compilación y pruebas, en cada pipeline del repositorio de un producto.

GitLab no permite que el propio archivo de pipeline de un repositorio quite o reemplace un trabajo inyectado.

Rechazar y advertir

Una regla da uno de dos veredictos:

Rechazar (deny) detiene el cambio. El trabajo falla, y GitLab solo integra un merge request cuando su pipeline termina bien. En main, un rechazo sobre el plan detiene el apply.
Advertir (warn) informa algo que hay que mirar, como un recurso que un producto declara por su cuenta en lugar de usar un módulo del golden path. Hoy una advertencia aparece en el registro del trabajo y no detiene nada. El diseño pide la aprobación de la plataforma y una entrada en un registro de excepciones por cada advertencia; esa parte todavía no está construida.

Una regla nueva de rechazo suele pasar su primera versión como advertencia, para que los equipos corrijan lo que rechazaría antes de que empiece a rechazarlo.

Mensajes escritos para actuar

Una regla que falla nombra el recurso que juzgó y qué tiene de malo, y muchas también dicen qué hacer en su lugar. Un bucket de almacenamiento otorgado a allUsers se rechaza con el consejo de exponerlo por el borde de la plataforma detrás del inicio de sesión único. A un trabajo que declara el entorno prod se le dice que despliegue con el componente tf-apply de la plataforma. Los mensajes están escritos para quien los lea después, una persona o un agente de código, así que el ciclo es corto: cambiar, validar, leer, corregir, validar otra vez.

Cómo se prueba una regla

Cada regla debería venir con un caso que debe aceptar y uno que debe rechazar, y el trabajo policy:test del pipeline de control-plane ejecuta todas las pruebas en cada cambio del paquete. GitLab integra un cambio en el paquete solo cuando ese trabajo pasa. Que cada regla nueva traiga sus propias pruebas es una convención que se cuida en la revisión, no algo que un trabajo verifique.

Qué se ejecuta dónde

airframe validate ejecuta la validación que no necesita credenciales: el formato y la validación de Terraform, OpenTofu y tflint donde están instalados, y el paquete de políticas sobre las raíces de Terraform, el archivo de pipeline y los Dockerfiles declarados. No ejecuta las verificaciones del catálogo, la compuerta de aprobación, las pruebas de la aplicación, el plan ni su precio; esos necesitan la plataforma y se quedan en el pipeline. Lee el paquete desde la copia de control-plane desde la que se instaló, no desde la versión de la plataforma que usa el producto.

Brechas conocidas

Estas están abiertas hoy, y los registros de la propia plataforma las enumeran:

Una advertencia no detiene nada, como se explicó arriba.
Un Dockerfile listado en .airframe/images.yaml con otro nombre, como Containerfile, se revisa solo cuando el merge request también cambia otro archivo que la validación vigila.
Un recurso sin ningún atributo labels pasa la regla de etiquetas, que revisa las etiquetas que un recurso declara.
airframe validate no ejecuta pruebas de módulos, ni la revisión de la especificación de la API, ni la verificación de compatibilidad de la API, aunque las instrucciones de la plataforma las nombran.

Dónde está

En el repositorio control-plane:

En el repositorio security-policies:

.gitlab/security-policies/policy.yml: lo que se inyecta, y las políticas de aprobación