Airframe

Por qué Airframe

Barreras de protección como código

Cada cambio a la infraestructura y al pipeline de un producto, sea quien sea o lo que sea que lo escribió, lo revisan reglas probadas en su merge request, y su plan otra vez antes de aplicar nada. Las personas aprueban para qué es un cambio; las reglas revisan cómo se hace.

Cómo se revisa un cambio

  1. Las reglas son código, con pruebas

    El paquete de políticas es un conjunto de reglas de Open Policy Agent en el repositorio control-plane. Conftest las ejecuta sobre el código Terraform y el archivo de pipeline de un producto en el merge request, y sobre el plan de Terraform antes de cada apply; desde la versión de la plataforma 2026.10.01-1, los Dockerfiles que un producto declara para sus compilaciones se revisan en cada merge request que cambia uno llamado Dockerfile, Dockerfile.* o *.Dockerfile. Por convención, cada regla trae un caso que debe pasar y uno que debe fallar, y una nueva regla de denegación suele pasar su primera versión como advertencia; el pipeline del propio paquete ejecuta todas las pruebas en cada cambio.

  2. Una validación que un producto no puede desactivar

    Las políticas de ejecución de pipelines de GitLab en el proyecto security-policies inyectan jobs que el propio archivo de pipeline de un repositorio no puede quitar ni reemplazar: la verificación de integridad de la compuerta de aprobación en cada pipeline del grupo, y la validación y la evidencia de pruebas en cada pipeline de un repositorio de producto.

  3. El mensaje dice qué está mal

    Una regla que falla nombra el recurso que evaluó y qué está mal en él, y muchas también dicen qué hacer en su lugar, con palabras escritas para quien las lea después, una persona o un agente de código.

  4. Solo los componentes de la plataforma despliegan

    El archivo de pipeline de un producto solo puede incluir los componentes de CI propios del repositorio control-plane, y ninguno de sus propios jobs puede declarar un entorno de despliegue. Un componente de cualquier otro lugar se deniega, y la compuerta de aprobación hace fallar un pipeline que incluya una versión revocada de la plataforma.

  5. Las personas aprueban la intención

    Cada merge request a una rama por defecto necesita la aprobación de una persona con nombre en el catálogo que no lo escribió ni hizo commits en él, nunca de un rol. Hoy, en todos los repositorios salvo security-policies, que contiene las propias reglas de aprobación, también necesita la aprobación de la compuerta de aprobación, que la agrega solo cuando los responsables que nombra el catálogo aprobaron el último commit: un aumento de presupuesto o un servicio nuevo necesita un líder de dominio, y cuando el líder no tiene cuenta, como en la demo, el equipo de plataforma lo reemplaza.

Pruébalo

Elige un cambio que un equipo podría proponer. El veredicto, la regla y el mensaje son los del paquete de políticas, juzgados en la versión de la plataforma que describe este sitio.

Un cambio propuesto
Denegado

Archivo: main.tf

resource "google_storage_bucket_iam_member" "public" {
  bucket = "orders-exports-k3d8"
  role   = "roles/storage.objectViewer"
  member = "allUsers"
}
  • Denegado iam.public-principal

    google_storage_bucket_iam_member.public: public principal "allUsers" is not allowed; expose through external-ingress behind IAP

    Nunca se concede nada a todo el mundo, y la denegación se aplica. Una ruta pública por el ingreso externo de la plataforma, detrás de IAP, está diseñada; hoy un servicio público recibe una ruta en el borde compartido, detrás del inicio de sesión único.

  • Advertencia naming.raw-resource

    google_storage_bucket_iam_member.public: a raw google_storage_bucket_iam_member in a product root needs a reason in the merge request (platform approval); compose the registry's modules where one covers it (skill airframe-naming)

    Un recurso que el producto declara por sí mismo, en lugar de componer un módulo, necesita una razón en el merge request. El paquete de políticas lo advierte; la aprobación de la plataforma para él está diseñada, y hoy una advertencia no detiene nada.

Estas reglas se ejecutan en tu portátil con airframe validate, y de nuevo en el job validate:policy del merge request.

Qué lo hace cierto

Las pruebas del paquete de políticas se ejecutan en cada cambio que recibe.
El job policy:test del repositorio control-plane ejecuta las pruebas unitarias de Conftest y los casos que deben pasar y fallar en cada merge request que cambia el paquete, y GitLab fusiona solo un merge request cuyo pipeline tiene éxito. Que una regla nueva traiga sus propias pruebas es una convención que sostiene la revisión, no una verificación.
Un repositorio de producto no puede saltarse la validación.
La política de ejecución de pipelines de productos en el proyecto security-policies inyecta los componentes validate y build-test en cada pipeline de los repositorios de los grupos de recorrido, y GitLab no deja que el propio archivo de un proyecto quite ni reemplace un job inyectado.
El archivo de pipeline de un producto incluye solo los componentes de la plataforma, y ninguno de sus propios jobs despliega.
Las reglas de pipeline del paquete deniegan una inclusión que no sea uno de los ocho componentes con nombre del repositorio control-plane, un job que declara un entorno y un job que dispara otro pipeline; la validación inyectada las ejecuta sobre el archivo del producto.
La aprobación de una persona a un merge request a una rama por defecto viene de una persona con nombre, no de un rol.
La política de aprobación lista a sus aprobadores por nombre y excluye al autor y a quienes hicieron commits. El job policy:approvers del proyecto security-policies informa cualquier rol, grupo o nombre que difiera de las personas activas del catálogo con una cuenta de GitLab. Lo que sostiene la lista allí es la aprobación de cada cambio por una persona con nombre, nunca la de su autor. La cuenta de servicio de la compuerta de aprobación es la única aprobadora de una política aparte y no puede dar la aprobación de la persona.
Una regla que deniega detiene el cambio.
Una denegación hace fallar el job de validación inyectado, y GitLab fusiona el merge request de un producto solo cuando su pipeline tiene éxito; en main, el job de políticas del componente tf-apply ejecuta el paquete sobre el plan, y el apply necesita que ese job pase. Las reglas de costo se ejecutan en cambio en el ejecutor: su rechazo hace fallar la verificación de estado Airframe cost del merge request, que debe pasar antes de que GitLab lo fusione, y detiene el plan en main.