Como comenzar con buen pie en la nube de AWS
Para implantar una solución sostenible a la hora de proporcionar servicios en diferentes geografías y/o tipologías de clientes, o incluso diversidad de proyectos, habitualmente proponemos la implantación progresiva de una Landing Zone a través del servicio Control Tower.
El servicio de AWS, Control Tower despliega una landing zone con 3 cuentas en una única organización: Root, Audit y Log Archive, además disponibiliza un Service Catalog compartido entre todas las cuentas con un procedimiento para crear nuevas cuentas dentro de la organización de forma semi-automática.
Para su funcionamiento y operativa Control Tower propone un sistema jerárquico en el que las cuentas se estructuran del siguiente modo:
Este servicio se apoya en AWS Organizations y AWS SSO para desplegar un patrón jerárquico de cuentas de una forma centralizada, pero sobre todo escalable y mantenible. Dicho servicio también propone formas de unificar la gestión de las cuentas con AWS IAM en forma de roles delegados y el cumplimiento de políticas propias o propuestas por AWS en todas las cuentas derivadas, aumentando de forma considerable la seguridad a través de mecanismos pasivos, aislamiento de cuentas y permisos efímeros a la vez que centralizados.
Esta jerarquía crea por defecto otras dos cuentas adicionales para la auditoría y traza del uso de servicios transversales (log), por otra parte, nuestra propuesta es completarla con una cuenta compartida para todos aquellos procesos y elementos transversales p.e. VPN, SCM, etc…. En este modelo, la cuenta root únicamente posee la facturación, la gestión de Organizaciones y SSO y el soporte (recomendamos contratar al menos business level), todas las demás acciones se realizan en las cuentas hijas, siempre en función de su nivel de particularidad o alcance.
Finalmente, añadir que la parte menos desarrollada de Control Tower es la automatización de la gestión de la propia instalación, sin embargo, gran parte del trabajo se realiza una única vez en las etapas iniciales del despliegue. En el caso de ser necesario extender los comportamientos de creación de nuevas cuentas, es posible a través de las herramientas propias de AWS como Cloudformation y Lambda.
¿Qué retos o puntos hay que tener en cuenta a la hora de implantar una Landing Zone con Control Tower?
- Integraciones con LDAP y/o ADFS previamente existente. Esta parte implica extender el servicio de AWS SSO configurado por defecto, lo que incluye validar que tenga soporte, y puede implicar bastante trabajo de integración.
- Es importante mencionar que debe quedar bien configurado el sistema de pago, una tarjeta a nombre de cliente si el importe es relativamente bajo, y si no cuenta bancaria, pero esto sólo se puede hacer tras un primer cobro (no siempre desde el primer momento).
- Es preferible que no se haya hecho nada previamente en la cuenta root, ya que en dicha cuenta gestionaremos muy pocas cosas
- Añadir una cuenta que ya existe es bastante complejo porque no suele reconocer los guardrail ni las UO de organizations.
- Es interesante si tienen en mente alguna restricción que se pueda convertir en políticas de seguridad adicionales que quieran implantar.
¿Qué personalizaciones he descubierto pueden servir de ayuda?
- Poner alarmas de gasto acordadas con el cliente. En umbrales del 25% incrementales respecto de lo que él estime como consumo mensual aceptable.
- Suelo crear para comenzar una cuenta shared dónde alojo cosas transversales a varias cuentas p.e. CI/CD, SCM,…
- También suelo crear una cuenta de networking para facilitar la creación de Transit Gateways o VPNs en el caso de que sean infraestructuras de nube híbrida.
- Por otro lado, habitualmente suelo eliminar los grupos por defecto y crear un grupo super-admin (acceso a la cuenta root y las de auditoría), un otro grupo DevOps Cross a las cuentas de entorno/proyecto y un grupo particular para cada proyecto/línea de trabajo.
- Contratar en la cuenta Root soporte business que nos habilita los ticket urgentes y los ticket de tipo técnico.
- Activar el permiso IAM de billing en la cuenta Root para que los admin de las cuentas hijas puedan ver el gasto de su cuenta.
- Activo algunos controles de GuardRail adicionales, especialmente los relativos a no dejar discos huérfanos y otros que generan gasto innecesario.
- Genero un grupo de correo y obtengo los usuarios Root con su MFA de TODAS y cada una de las cuentas hija, por si hubiese algún problema de seguridad/accesos. Una herramienta útil para ello son los tópicos:
- proyecto-x-grupo@keepler.io => root
- proyecto-x-grupo+log@keepler.io => log
- proyecto-x-grupo+audit@keepler.io => auditoria
¿Cuánto tiempo lleva montarlo y configurarlo?
Está operativo en un par de horas, diría que dejarlo completamente operativo, entre crear los usuarios, grupos, etc,… se invierten 1 ó 2 día de trabajo. No es una labor muy exigente, en general se trata de asistentes guiados que hacen casi todo el trabajo.
🎭 Suscríbete para leer sin límites
📚 Lee otro material relacionado
⭐ Mira mis recomendaciones
📨 Apúntate a mi lista
