landing-zone

El repositorio landing-zone construye la parte de Google Cloud sobre la que se apoya cada producto: las carpetas y políticas de la organización, las redes compartidas, las fábricas que crean los proyectos y las identidades de cada producto, y el registro de auditoría. También es donde vive el diseño escrito de la plataforma: la especificación, los contratos que implementa cada repositorio, los registros de decisiones y un manual ilustrado. Si quiere saber por qué algo en Airframe es como es, la respuesta suele estar en la carpeta docs de este repositorio.

Para qué sirve

Una landing zone es el terreno preparado de una organización en la nube: la estructura, las reglas y los servicios compartidos que tienen que existir antes de que cualquier equipo pueda desplegar algo con seguridad. En Airframe, todo eso es código Terraform en este repositorio, aplicado por pipelines, así que la base se revisa y se registra como todo lo demás.

Qué contiene

Las raíces, cada una un directorio de código Terraform con su propio estado y su propia identidad:

organisation: las políticas de toda la organización, como no permitir claves de cuentas de servicio ni direcciones públicas de bases de datos, y la política de denegación que protege la carpeta de la organización de demostración.
folders: una carpeta por recorrido, dominio y contexto, desde el catálogo.
project-factory: una fábrica por dominio, que crea los dos proyectos de cada producto, sus identidades de plan y de apply, sus lugares para el estado de Terraform, su presupuesto una vez que tiene facturación, y su salida Ready; y una para los proyectos propios de la plataforma.
groups: los grupos de Google de los equipos, de los líderes y de los usuarios de cada producto, con sus miembros desde el catálogo.
network y perimeters: las dos redes compartidas, producción y no producción, el borde compartido que le da a cada producto su nombre de host detrás del inicio de sesión único, el DNS, y los perímetros de VPC Service Controls, que hoy funcionan en modo de prueba.
wif y pam: el proveedor de identidades que da a los trabajos de pipeline sus identidades de corta duración, y las concesiones de Privileged Access Manager para las personas.
audit y state: la exportación del registro de auditoría y los buckets que guardan el estado de Terraform de cada raíz.

Los documentos, en docs/:

architecture.md, la especificación: qué se construye y por qué, con las alternativas consideradas;
contracts.md: los nombres y las formas que debe usar cada repositorio, desde los campos del catálogo hasta los nombres de host;
adaptations.md, bootstrap.md y bootstrap-log.md: dónde esta implementación se aparta del diseño original, las pocas cosas creadas a mano al principio, y el registro de cada paso a mano desde entonces;
adr/, rehearsals/ y reviews/: decisiones, ensayos de reconstrucción y de retiro, y revisiones de la implementación con lo que respondió a cada hallazgo;
guides/: el manual, una guía ilustrada por cada vista de la plataforma, empezando por la vista general.

Cómo se conecta

Lee el catálogo. Las carpetas, los grupos y las fábricas de proyectos crean lo que describe el catálogo, y la cadena después de un merge en el catálogo inicia primero el pipeline de este repositorio.
Todo lo demás lo lee. La salida Ready de una fábrica de proyectos le dice a las propias raíces de un producto, a las raíces de GitLab de control-plane y a las raíces de operations qué existe. La publicación de la red les dice a las fábricas qué proyectos están conectados.
Los productos le publican. Las rutas de un producto se publican en un bucket compartido, y la raíz de red compone el borde compartido a partir de ellas, así que un producto nunca tiene las credenciales del borde.

Quién lo cambia, y cómo

Los cambios son merge requests aprobados por el equipo de plataforma. En main, el pipeline planifica cada raíz, ejecuta el paquete de políticas sobre el plan y lo aplica con la identidad propia de esa raíz. Las raíces de red y de perímetros planifican después de que las fábricas aplicaron, así que los proyectos de un producto nuevo llegan a la red en el mismo pipeline.

Tres raíces no las aplica el pipeline: organisation, audit y wif. Un pipeline que pudiera reescribir el modelo de identidades sería el más poderoso de la plataforma, así que estas se aplican desde la laptop de un mantenedor con una concesión de tiempo limitado que aprueba otro miembro del grupo de plataforma. El pipeline igual las planifica todos los días con una identidad de solo lectura, así que cualquier cambio hecho con una concesión aparece como deriva.

Todos los días, el pipeline programado también planifica cada raíz para detectar deriva, y le pregunta a Policy Analyzer de Google quién tiene qué rol en la organización, y falla si alguien tiene uno que no debería.

Dónde está

En el repositorio landing-zone: