La landing zone
Una cuenta para todos
Cada equipo tiene ya su VPC, hecha con el módulo de plataforma y con su propio estado. Pero todas viven en la misma cuenta de la nube, junto al router de tránsito y el túnel al CPD que construyó la serie de redes. Los equipos se separan por VPC, por permisos y por etiquetas: el rol del pipeline de Reporting puede tocar lo que lleva la etiqueta equipo=reporting, y nada más.
Hasta que alguien de Reporting, para ir más rápido, cambia los permisos de ese rol a "*". Y Transferenciasver en el mapa, que se muda ahora a la nube, pregunta por qué su VPC tarda dos semanas.
Este último episodio organiza toda la nube de BCPS Bank como una landing zone: el sitio preparado donde aterriza cada equipo, con sus cuentas, su red y sus reglas puestas antes de que llegue. Es la red de la serie de redes, esta vez construida y gobernada con código.
Toda la nube del banco
Arriba de cada panel, la red de plataforma: el router de tránsito y el túnel al CPD. Debajo, los equipos, en producción y en desarrollo. A la izquierda, una cuenta compartida: las celdas son VPC dentro de la misma cuenta, y hay un guardarraíl que revisa cada plan. A la derecha, una landing zone: cada celda es una cuenta propia dentro de una organización, las cuentas se dan de alta por código y los guardarraíles están en el plan y en la propia organización.
Da de alta la cuenta de Transferencias, provoca un permiso de más y pide una base de datos pública. El interruptor endurece las políticas del pipeline. El último botón repite, con todo esto puesto, el cambio a mano del episodio 1.
Qué ha pasado
La cuenta es la frontera más fuerte
Una cuenta de la nube (una subscription en Azure, un project en Google) es la unidad que el proveedor aísla por completo: sus recursos, sus permisos, su factura y sus límites. Un permiso concedido dentro de una cuenta no puede salir de ella, salvo que alguien lo haya abierto a propósito.
Por eso el mismo error tiene dos radios. A la izquierda, el rol de Reporting con permisos de administrador puede tocar todo lo de la cuenta: las VPC de los demás equipos, las bases de datos de producción, el router de tránsito y el túnel al CPD. Las etiquetas y las condiciones de los permisos acotaban lo que se hacía bien; un permiso mal dado se las salta. A la derecha, el mismo rol vive en la cuenta de Reporting de desarrollo y todo lo que puede romper está dentro de ella: 40 recursos, ninguno crítico.
Es el radio de impacto del episodio 4 llevado al último nivel: allí se partía el estado para que un apply rompiera menos; aquí se parte la nube, para que un error, sea de Terraform o de una persona, no salga de su cuenta. Y la separación por entorno del episodio 4, desarrollo y producción, encuentra aquí su sitio natural: cuentas distintas.
Pedir una cuenta es una pull request
Tener una cuenta por equipo y entorno solo funciona si crear una cuenta es barato. En la landing zone, el alta es un cambio en código: una PR que añade un bloque al repositorio de cuentas.
module "cuenta_transferencias_pro" {
source = "registro.bcps/plataforma/cuenta/nube"
version = "~> 3.2"
equipo = "transferencias"
entorno = "pro"
tamaño = "mediana"
}El pipeline de plataforma crea la cuenta, el rol de su pipeline, su VPC con el módulo del episodio 5 y su adjunto al router de tránsito, por oleadas, como en el episodio 2. El equipo recibe una cuenta que ya tiene red, permisos y camino al CPD. Es un módulo profundo de otro nivel: tres entradas, y detrás, todo lo que la organización necesita que tenga cada cuenta.
La red hub, en la cuenta de plataforma
El router de tránsito y el túnel al CPD viven en una cuenta de red que solo toca plataforma. Los equipos no los gestionan: se enganchan, con el adjunto que crea su propia cuenta al darse de alta. Es el hub-and-spoke de la serie de redes, con la frontera de las cuentas encima: un equipo puede romper su VPC, pero no el camino de los demás al CPD.
Guardarraíles: en el plan y en la nube
Un guardarraíl es una regla que impide lo que nadie debería hacer nunca: una base de datos abierta a internet, recursos fuera de la región europea, un bucket público. Se ponen en dos sitios. En el plan, como policy as code: antes de aplicar, una herramienta revisa el plan contra las políticas y lo para si alguna no se cumple. Y en la organización: la propia nube deniega la llamada a la API, venga de donde venga.
Pide la base de datos pública. En los dos paneles, el plan la rechaza. Pero quien la quería va a la consola, y ahí se ve la diferencia: a la izquierda, la consola no pasa por el pipeline y la base de datos se crea; a la derecha, la organización la deniega, porque el guardarraíl no depende de que el cambio pase por Terraform.
Cuándo hace daño: los guardarraíles que devuelven a la consola
Activa las políticas estrictas: cada cambio necesita la revisión de plataforma, doce etiquetas obligatorias y una aprobación de seguridad. Los equipos, con cosas urgentes que hacer, vuelven a la consola para todo lo que la organización no prohíbe: seis cambios a mano en una semana. El drift que el episodio 1 enseñó a vigilar vuelve, multiplicado por equipos. Un guardarraíl sirve si prohíbe lo que nadie debe hacer y deja hacer rápido todo lo demás; si hace lento lo normal, empuja a la gente fuera del código.
Y repite el alta de Transferencias con las políticas estrictas. La PR espera detrás de otras seis, porque todas pasan por Marta. La landing zone automatiza el alta, pero si cada alta necesita que una persona de plataforma la revise a mano, plataforma se convierte en el cuello de botella de toda la organización. Lo que debe revisar una persona es lo que cambia la landing zone; lo que la usa como está previsto, debería pasar solo.
Criterio
| Una cuenta compartida | Landing zone | |
|---|---|---|
| Montarlo | Nada: ya existe | Semanas: organización, cuentas base, pipeline de altas, políticas |
| Un permiso mal dado | Alcanza a todos | No sale de su cuenta |
| Un equipo nuevo | Una VPC y permisos por etiqueta | Una PR; la cuenta llega con todo |
| Guardarraíles | En el plan, y en la consola no | En el plan y en la organización |
| Coste de gestión | Bajo, hasta que falla | Un equipo de plataforma que la mantenga |
| Bueno para | Una organización pequeña, un equipo o dos, sin datos regulados | Varios equipos, producción con datos sensibles, un regulador que pregunta |
La cuenta compartida no es un error: para una empresa con un equipo, la landing zone es trabajo que no se amortiza, y un guardarraíl en el plan ya evita lo peor. El momento de cambiar suele ser el segundo equipo con producción propia, o la primera auditoría.
-
¿Hay varios equipos con producción, o datos que un regulador vigila?Un banco lo tiene desde el primer día.landing zone: cuenta por equipo y entorno
- Una cuenta, separada por VPC y permisos, con guardarraíles en el plan. Y como mínimo, producción en otra cuenta.
En el mundo real
Cada nube tiene su forma de organizar cuentas y sus guardarraíles de organización. En AWS, Organizations agrupa las cuentas en unidades organizativas, y las service control policies ponen el techo de lo que cualquiera puede hacer en ellas; Control Tower monta una landing zone de partida, y Account Factory for Terraform da de alta cuentas con una PR. En Azure, los management groups agrupan suscripciones y Azure Policy deniega o corrige lo que no cumple; las Azure Landing Zones son la arquitectura de referencia. En Google Cloud, la organización se reparte en carpetas y proyectos, con organization policies, y Cloud Foundation Fabric es su equivalente.
Para las políticas en el plan, lo habitual es Open Policy Agent (con Conftest), Sentinel en HCP Terraform, o analizadores como Checkov y Trivy, que traen cientos de reglas hechas. Se ejecutan en el pipeline, entre el plan y el apply, igual que los tests.
La landing zone de verdad trae más cuentas que las de los equipos: una para los registros de auditoría, que nadie más puede borrar; una de seguridad, desde la que se vigila a las demás; una de red, como la de plataforma en este episodio; y una de «sandbox» donde probar sin miedo, con presupuesto limitado. Y la de gestión, la raíz de la organización, que no debería tener nada dentro.
Final de la serie
El episodio 1 empezó con una regla abierta a mano de madrugada, que el siguiente apply deshizo. El último botón repite ese cambio con todo lo que ha ido apareciendo: una PR con un plan que dice ~1, un lock que pone en fila a quien llegue después, un pipeline que es la única mano, un radio que no sale de la cuenta de la app de producción y un guardarraíl que ha revisado el plan. Ninguna de esas piezas lo resuelve sola.
Por el camino, el estado ha sido una base de datos en cada episodio: una réplica que diverge de la nube, un grafo que ordena, un fichero que dos personas se pisan, algo que se parte para que rompa menos, un contrato entre equipos y, al final, una frontera. Escribir el código era lo fácil; lo que se ha diseñado es el estado: dónde vive, quién lo toca y cuánto rompe un apply.
← Todos los episodios · Episodio 1: Alguien lo cambió a mano · La serie de redes · Transferencias en el mapa de BCPS Bank