El arranque

El arranque es la lista corta de cosas que una persona crea a mano para poner en marcha Airframe, antes de que exista algún pipeline que pueda crearlas. Cada paso hace algo que el siguiente necesita, y cada uno deja un registro escrito, para que el comienzo de la plataforma se pueda auditar como todo lo que vino después. Esta página recorre los catorce pasos en orden y explica por qué ninguno puede esperar a un reconciliador.

La regla, y el registro

La primera vez que algo se crea a mano es la última: un paso posterior lo pone bajo gestión, casi siempre importándolo en una raíz de Terraform. El runbook es docs/bootstrap.md de landing-zone. Su registro es docs/bootstrap-log.md, una fila por paso: la fecha, la cuenta usada, lo que se creó (identificadores, nunca valores secretos), dónde se guarda cada secreto (por su nombre en Secret Manager) y el commit que lo puso bajo gestión. Donde el runbook y el registro no coinciden, el registro tiene razón y se corrige el runbook.

El registro también anota dónde la práctica se apartó del plan. El runbook pide llaves de seguridad como único segundo factor en las cuentas de administración; las primeras filas del registro dicen que se exigió la verificación en dos pasos para todos y que la exigencia de llaves de seguridad quedó para después. El arranque de Airframe se hizo el 2026-09-04 y el 2026-09-05.

Dos cuentas de administración hacen el trabajo: una cuenta de Workspace con Organization Administrator, y la cuenta de GitLab dueña del grupo de primer nivel. Las dos se usan solo aquí y en procedimientos excepcionales, y el resto del tiempo quedan con la sesión cerrada.

En las consolas, antes de que se ejecute código

Condiciones previas. La organización, la cuenta de facturación, el grupo de GitLab, el stack de Grafana Cloud y el dominio ya existen, como enumeran los requisitos previos. Son el lugar donde se ejecuta el código, así que ningún código puede crearlos. Sus identificadores son la primera fila del registro.
Cuentas de administración y grupos, en la consola de administración de Workspace. Crea las cuentas de administración, el grupo de la plataforma y el grupo de emergencia. Un reconciliador necesita una identidad con la que ejecutarse, y estas cuentas son donde empieza la identidad. Los grupos los importa después la raíz de grupos de landing-zone.
Roles para la ventana de arranque, desde la línea de comandos. La cuenta de administración recibe roles a nivel de organización que vencen a los catorce días. Las primeras aplicaciones necesitan roles que todavía no tiene ninguna identidad de pipeline. A la lista del runbook le faltaban cuatro roles, que aparecieron con aplicaciones fallidas, y el ADR-0002 de landing-zone registra el conjunto completo.
Cuota de facturación y presupuesto, en la consola de Cloud. Una solicitud para subir la cuota de proyectos de la cuenta de facturación, y un presupuesto en la cuenta. Google recibe la solicitud mediante un formulario, y Airframe la hizo el primer día. El presupuesto se importa en la raíz de carpetas en el paso 7.
El primer proyecto y el bucket de estado, con la línea de comandos. Un proyecto de ejecución y un bucket para el estado de Terraform. Terraform necesita dónde guardar su estado antes de que pueda ejecutarse su primera raíz. La raíz de carpetas se hace cargo del proyecto en el paso 7, y la raíz de estado del bucket en el paso 8, agregándole su clave de cifrado.
El dueño en GitLab y un token de arranque. La cuenta dueña del grupo y un token de acceso personal que vence a los catorce días. GitLab.com no crea un administrador por ti, y la primera aplicación de la raíz de GitLab necesita una credencial. El token se revoca en el paso 14.

Desde una laptop, dentro de la ventana

Estos pasos son aplicaciones de Terraform desde la laptop de un mantenedor, porque todavía no existe ningún runner. Su estado vive en el bucket de estado de la plataforma, y el registro anota el commit que aplicó cada uno.

La raíz de GitLab, roots/gitlab de control-plane, con el token de arranque: los grupos, los repositorios de la plataforma y sus protecciones, los roles personalizados, las cuentas de servicio y las políticas de seguridad, escritas pero todavía no vinculadas al grupo.
Carpetas, políticas y los proyectos de la plataforma, roots/folders, roots/organisation y la fábrica de proyectos de la plataforma, en landing-zone: las carpetas, las políticas de organización y las políticas de denegación, y los proyectos propios de la plataforma.
Estado e identidad, roots/state y roots/wif: los buckets de estado con sus claves de cifrado, y el proveedor de federación de identidades de carga de trabajo con las vinculaciones de las raíces de la plataforma y del ejecutor.
La red y los runners, la primera versión de la raíz de red, y después el runner de confianza. Registrar un runner en GitLab da un token de autenticación, que una persona guarda en Secret Manager: ese es el segundo token a mano, y el del runner sin confianza es el tercero. El paso termina cuando un pipeline en la main de control-plane ejecuta un job en el runner de confianza y obtiene una credencial de corta duración.

Desde ahí, las raíces se aplican por pipeline. Tres siguen aplicándose desde una laptop, con una concesión de tiempo limitado que aprueba otro miembro del grupo de la plataforma: organisation, audit y wif. Necesitan roles a nivel de organización o de administración de IAM que ninguna identidad de pipeline tiene, y wif, que les da sus roles a todas las demás identidades, haría de su pipeline el más poderoso de la plataforma (ADR-0002 y ADR-0008 de landing-zone).

Por pipeline, y las últimas manos

Todas las demás raíces, cada una con un merge request normal: grupos, la red completa, los perímetros en modo de prueba, las concesiones, las primeras entradas del catálogo, las raíces de operations, el ejecutor y la compuerta de aprobación. La raíz de auditoría es la excepción: se aplicó desde una laptop dentro de la ventana, como las otras dos de arriba. Un rol se asigna a mano en la consola de administración de Workspace: Groups Administrator para la identidad de la fábrica de grupos, que la fábrica necesita antes de poder ejecutarse. El registro lo anota.
Tokens de Grafana Cloud, en el portal de Grafana. Las políticas de acceso y sus tokens, y el cliente del inicio de sesión único. El stack gratuito se crea a mano, los alcances de una política de acceso solo cambian en el portal, y ningún valor secreto puede entrar en el estado de Terraform: las raíces crean cada secreto por su nombre, y un mantenedor agrega el valor.
Concesiones, y la ventana cerrada. La raíz pam se aplica por pipeline y crea los derechos de Privileged Access Manager. Se pide una concesión, la aprueba una segunda persona, se usa y se deja vencer, como ensayo. Después se le quitan a mano todos los roles de la ventana a la cuenta de administración, que se queda solo con Organization Administrator. Airframe cerró su ventana el 2026-09-05, trece días antes de tiempo.
Servidores de nombres en el registrador. La raíz de red ya creó la zona DNS pública; una persona configura en el registrador, que está fuera de Google Cloud, los servidores de nombres del dominio y el registro de firma, y después comprueba que el correo sigue llegando. Cuando la compuerta responde en su nombre de host, la cuenta de administración de GitLab vincula las políticas de seguridad al grupo desde una laptop, con una segunda aplicación de la raíz de GitLab: la política de pipelines de todo el grupo inyecta gate:integrity en cada pipeline, y el trabajo falla de forma cerrada hasta que la compuerta sirve, así que vincularlas antes detendría el pipeline que despliega la compuerta.
La renuncia a los privilegios. Se revoca el token de arranque, la cuenta de administración de GitLab queda como única Owner del grupo, ninguna cuenta de uso diario tiene Maintainer ni Owner en ningún lugar, y la revisión diaria de quién tiene qué rol en la organización se ejecuta por primera vez. Los pipelines programados los crea a mano un mantenedor que puede hacer merge, porque una programación se ejecuta con los permisos de su dueño. Las cuentas de administración cierran la sesión.

Después del arranque

El registro no se cierra. Cada paso posterior hecho a mano agrega una fila, como una aplicación desde una laptop de una de las tres raíces con una concesión, o un cambio en la raíz de GitLab con el procedimiento excepcional: un token de un día de la cuenta de administración de GitLab, usado desde una laptop y revocado después. El runbook también enumera lo que nunca se hace a mano, como los proyectos de los productos, los repositorios, los grupos y los registros DNS: necesitar hacer a mano una de esas cosas se registra como un error de un reconciliador.

Repetir el arranque está diseñado: el runbook dice que los pasos 1 a 5 se pueden verificar a simple vista, que las aplicaciones posteriores convergen, y el registro nombra lo que una repetición tendría que importar. El runbook prevé una reconstrucción completa en una segunda organización de prueba vacía, y todavía no existe ningún registro de una.

Dónde está

En el repositorio landing-zone: