Antes de emprender cualquier transformación, conviene tener un plan. Uno de los mayores retos en empresas con iniciativas de gran envergadura es decidir por dónde empezar, a quién involucrar y con quién trabajar para que todo salga bien. Sin importar si tu organización tiene una estructura divisional, matricial, plana u otra, fijar metas ambiciosas y arrancar pruebas de concepto (PoCs) de manera temprana y constante te pondrá en el camino correcto.
Este artículo plantea un enfoque con criterio para estructurar tu infraestructura en la nube. Se basa en experiencia reciente liderando transformaciones cloud en empresas de FinTech (sector regulado) con productos SaaS y rediseñando aplicaciones legacy para que corran sobre el servicio de Kubernetes administrado de Google, GKE. La idea es resaltar las áreas clave a planificar y diseñar: red, presupuesto, DevOps, seguridad y compliance. En próximos artículos profundizaré en muchos de estos temas con ejemplos específicos y demos.
Cómo estructurar tu empresa en Google Cloud Platform
TL;DR
- Asegúrate de tener alineación organizacional
- Elige tu propia aventura
- Configura la identidad con grupos de usuarios y roles
- Centraliza tus redes con VPCs compartidas
- Planifica todos tus recursos
- Etiqueta tus recursos para mejorar los reportes
- Configura alertas de presupuesto
- Organiza tus repositorios de código fuente para IaC
- Configura alertas de seguridad y monitoreo
- Usa un host bastión (jump)
- Protege tus datos
- Usa Cloud Security Command Center
- Documenta y prueba tus planes de Disaster Recovery y continuidad de negocio
- Apóyate en expertos que ya lo hayan hecho antes
Asegúrate de tener alineación organizacional
Aunque este artículo se centra en las funcionalidades de Google Cloud Platform (GCP), sería un descuido no reconocer al CEO de AWS, Andy Jassy, por resumir con elegancia las cuatro claves del éxito en una transformación cloud y, me atrevería a decir, del éxito de cualquier iniciativa:
- Convicción y alineación del equipo de liderazgo senior
- Metas ambiciosas top-down
- Capacita a tus builders
- No dejes que la parálisis [por análisis] te detenga antes de empezar
Mi mantra personal cuando pruebo cosas nuevas es: "primero hazlo funcionar, luego hazlo bien y después hazlo rápido".
Elige tu propia aventura
Google tiene excelentes recursos en línea sobre mejores prácticas para empresas, y la siguiente ilustración muestra los pasos recomendados para Secure Google Cloud Services. Las necesidades de cada organización varían, así que esta hoja de ruta es un excelente punto de partida para planificar tu infraestructura específica o conocer lo que está disponible.
Fuente: Google
Configura la identidad con grupos de usuarios y roles
Conviene arrancar con una política de menor privilegio y deshabilitar de inmediato la creación de proyectos a nivel de la organización. Solo DevOps, Billing y OrgAdmins deberían tener esa capacidad e, idealmente, solo una service account en DevOps para tu automatización de infraestructura (es decir, Terraform). Siempre que sea posible, no agregues personas individuales a tu IAM.
- Organization Administrators ([email protected])
- Network Administrators ([email protected])
- Security Administrators ([email protected])
- Billing Administrators ([email protected])
- DevOps ([email protected])
- Development ([email protected])
- DataScience ([email protected]) [opcional]
Una vez creados estos grupos, ya sea opcionalmente con Cloud Identity (conectándolo a tu AD o IdP existente) o en tu organización de GSuite, agrega al menos una persona por grupo. Después, asigna los roles necesarios solo cuando se requieran a cada grupo, ya sea a nivel de Organization o de Folder.
Fuente: Google
Si trabajas con GitOps, los equipos de desarrollo pueden desplegar cualquier workload* en sus respectivos namespaces del cluster de Kubernetes mediante pipelines de CI/CD desde el control de código fuente. Este enfoque te ayuda a gestionar accesos y cuotas para un mejor control y presupuesto del gasto en la nube.
*solo binarios aprobados desde un repositorio privado de imágenes confiable
Centraliza tus redes con VPCs compartidas
En industrias altamente reguladas o cuando hay que mantener compliance como SOC 2, los controles pueden exigir una estricta separación de responsabilidades. Una práctica común en empresas es separar la gestión de la red de DevOps y del desarrollo de aplicaciones. GCP lo facilita con su funcionalidad de VPC compartida y su elegante jerarquía de proyectos, en concreto los proyectos host y de servicio.
Diseña y planifica tu red para evitar colisiones, y elimina todas las redes default dentro de los proyectos. ¡Me lo agradecerás después!
Como mencioné, este es un enfoque con criterio, pero el tuyo puede variar. La mejor práctica que recomiendo es encapsular tus proyectos de servicio dentro de un proyecto host y centralizar la configuración de la red en un solo lugar, otorgando acceso a estos proyectos únicamente al grupo de network administrators.
Al asignar IPs para tus subnets, dependiendo de tu escala y planes de crecimiento, un rango CIDR /16 para una VPC debería sobrar (65.000 direcciones). Sin embargo, Kubernetes requiere muchas IPs para servicios y pods, ya que se asignan de forma dinámica para contenedores efímeros. Te sugiero reservar un rango adicional sin usar para IPs secundarias, como se muestra abajo:
- subnet dentro del rango /16 de la VPC: k8s-nodes-prod (10.10.0.0/22)
secundaria: k8s-services-prod (10.80.64.0/22)
secundaria: k8s-pods-prod (10.80.0.0/18)
subnet: bastion-prod (10.10.64.0/29)
- subnet dentro del rango /16 de la VPC: k8s-nodes-stage (10.11.0.0/22)
secundaria: k8s-services-stage (10.81.64.0/22)
secundaria: k8s-pods-stage (10.81.0.0/18)
subnet: bastion-stage (10.11.64.0/29)
- subnet dentro del rango /16 de la VPC: k8s-nodes-demo (10.12.0.0/22)
secundaria: k8s-services-demo (10.82.64.0/22)
secundaria: k8s-pods-demo (10.82.0.0/18)
subnet: bastion-demo (10.12.64.0/29)
- subnet dentro del rango /16 de la VPC: k8s-nodes-qa (10.13.0.0/22)
secundaria: k8s-services-qa (10.83.64.0/22)
secundaria: k8s-pods-qa (10.83.0.0/18)
subnet: bastion-qa (10.13.64.0/29)
- subnet dentro del rango /16 de la VPC: k8s-nodes-dev (10.14.0.0/22)
secundaria: k8s-services-dev (10.84.64.0/22)
secundaria: k8s-pods-dev (10.84.0.0/18)
subnet: bastion-dev (10.14.64.0/29)
Esto deja espacio de sobra dentro de tu VPC para subnets adicionales destinadas a servidores de bases de datos u otros recursos.
Planifica todos tus recursos
Google Cloud Platform organiza los recursos por organización, folder y proyecto. Esto facilita la gestión de usuarios y grupos sin caer en la locura de múltiples cuentas que existe en otras plataformas. Muchas empresas que adoptaron la nube tempranamente terminaron construyendo soluciones a medida para mantener este "caos" de cuentas y permisos, lo cual es una pesadilla para InfoSec y compliance: GCP lo resolvió bien.
├── DevOps
│ └── project-devops
│ ├── bucket-terraform-state
│ ├── cluster-devops
│ │ ├── namespace-cicd
│ │ └── namespace-vault
│ ├── sink-application-logs
│ └── sink-audit-logs
├── RnD
│ ├── Non-Production
│ │ └── project-shared-network-nonprod
│ │ ├── sink-application-logs
│ │ ├── sink-audit-logs
│ │ ├── vpc-demo-10-12-0-0
│ │ │ └── project-demo
│ │ │ ├── cluster-demo
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ ├── vpc-dev-10-14-0-0
│ │ │ └── project-development
│ │ │ ├── cluster-development
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ └── vpc-qa-10-13-0-0
│ │ └── project-development
│ │ └── cluster-qa
│ │ ├── namespace-team1
│ │ ├── namespace-team2
│ │ └── namespace-vault
│ ├── Production
│ │ └── project-shared-network-prod
│ │ ├── sink-application-logs
│ │ ├── sink-audit-logs
│ │ ├── vpc-prod-10-10-0-0
│ │ │ └── project-production
│ │ │ ├── cluster-production
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ └── vpc-stage-10-11-0-0
│ │ └── project-stage
│ │ ├── cluster-stage
│ │ │ ├── namespace-team1
│ │ │ ├── namespace-team2
│ │ │ └── namespace-vault
│ │ ├── sink-application-logs
│ │ └── sink-audit-logs
│ └── project-monitoring
│ ├── bucket-development-logs
│ ├── bucket-production-logs
│ ├── workspace-development
│ └── workspace-production
└── Security
└── project-security
└── bucket-audit-logs
Etiqueta tus recursos para mejorar los reportes
Uno de los retos más comunes y de las mayores fuentes de confusión en las nubes públicas es el billing, los reportes y el control de costos. Una forma de gestionar tus costos es diseñar tu infraestructura con namespaces basados en equipos, como mostré arriba. Esto acelera el onboarding y la productividad de los desarrolladores, y evita una curva de aprendizaje pronunciada o un pool de talento más reducido. Otra buena práctica es etiquetar los recursos con tags/labels para luego poder establecer alertas, presupuestos y reportes.
Otro colega mío escribió este artículo sobre "Auto Tagging Google Cloud Resources" usando nuestra herramienta open-source, IRIS. Hay muchos otros buenos artículos sobre el tema, así que conviene planificar tus tags con anticipación y ahorrarte dolores de cabeza después.
Tags sugeridos por recurso:
- Owner: quién es responsable actualmente (puede haber cambiado de equipo)
- Creator: quién lo creó originalmente (puede que surjan dudas más adelante)
- Project: por ejemplo, my-company-production, para una mejor agrupación
- Working Hours: ahorra hasta un 60% al programar automáticamente recursos de dev con Zorya
Configura alertas de presupuesto
Muchos CFOs le tienen miedo a la nube por la falta de visibilidad y por el riesgo de un gasto descontrolado por culpa de una mala configuración. Con las alertas de presupuesto puedes hacer seguimiento del gasto diario y reaccionar rápido para alinear el gasto en la nube con los ingresos de la empresa. Es buena idea compartir información de costos con tus equipos y pedirles a los líderes que se reúnan a revisar y monitorear el presupuesto con frecuencia.
Organiza tus repositorios de código fuente para IaC
Una vez que tengas el plan de tu jerarquía de recursos, te enfrentarás a un escenario tipo huevo o gallina. ¿Aprovisionas todo con Terraform y, de ser así, cómo obtiene Terraform los permisos para construirlo todo? La sugerencia es que tu Org Admin cree el folder y el proyecto de DevOps, y que tu equipo de DevOps cree una Service Account de Terraform con los permisos necesarios para crear y eliminar proyectos, etc. Empieza con lo mínimo indispensable y, conforme aparezcan errores, agrega los roles necesarios según se requieran.
Uno de mis colegas escribió un excelente artículo sobre "Refactoring Terraform The Right Way" que se alinea con las sugerencias del equipo experto de Gruntwork.io, creadores de Terragrunt. En resumen: separa tus recursos, servicios y entornos en vivo en tres repositorios distintos y gestiona los permisos de los grupos en tu control de código fuente en consecuencia.
Configura alertas de seguridad y monitoreo
El monitoreo y las alertas deberían estar al frente de tu proceso de planificación, y por suerte hay muchas funcionalidades integradas en Google Cloud Platform que lo facilitan. El escaneo del benchmark CIS dentro del Cloud Security Command Center (CSCC), descrito más abajo, detecta el monitoreo faltante y te da instrucciones paso a paso para configurar correctamente cada proyecto. Más detalles sobre CSCC más adelante.
Para tu comodidad, aquí tienes un Gist con las configuraciones de monitoreo recomendadas.
Usa un host bastión (jump) para el acceso
Por simplicidad omití las VMs para los hosts bastión en el diagrama anterior, pero la mejor práctica para el acceso seguro es usarlos. Te sugiero agregar un rango de subnet por proyecto para una VM bastión, eliminar todas las IPs externas y configurar clusters privados. Crea un managed instance group de uno, así GCP levantará una nueva instancia si la actual falla. Puedes conectarte al bastión vía VPN o, con un enfoque más moderno y seguro, mediante Cloud Identity Aware Proxy (IAP). Y puedes blindar aún más tu bastión restringiendo las llaves SSH de los usuarios.
Fuente: Google
Existen varios artículos sobre mejores prácticas de Kubernetes, pero este de los engineers de Google sobre "Completely Private GKE Clusters With No Internet Connectivity" es una buena referencia y reafirma la estructura básica que se propone arriba.
Protege tus datos
Tienes que planificar y diseñar tu infraestructura para cumplir con las políticas que defina el equipo de seguridad de tu organización, y a menudo eso incluye distintos grados de cifrado. Los recursos de GCP están cifrados en reposo por defecto, pero deberías identificar tus necesidades de llaves de cifrado (administradas por Google, autoadministradas, BYOK) tanto en reposo como en tránsito.
También puede que quieras aislar el acceso a los datos dentro de tu organización, hasta el nivel de personas o aplicaciones. Esto se logra con VPC Service Controls, como se ilustra abajo.
Si estás enviando logs o datos para monitoreo, como se ve en el ejemplo de jerarquía de recursos, puedes configurar tus log sinks para aprovechar las APIs de Cloud Data Loss Prevention (Cloud DLP) y eliminar casi 100 tipos de datos PII antes de almacenarlos.
Usa Cloud Security Command Center
Una joya escondida de GCP es Cloud Security Command Center. Este producto ofrece un panel único para gestión de activos, detección de amenazas y anomalías, WAF y escaneo de vulnerabilidades. Una de las funcionalidades que más me gustan es el escaneo: puedes configurar qué proyectos escanear, pero no puedes controlar cuándo se ejecuta (1 o 2 veces al día). Resalta las violaciones a los benchmarks CIS y NIST en cada proyecto y recurso, con remediación paso a paso.
Nota: los nuevos precios dividirán CSCC en dos niveles (free, premium).
Cloud Security Command Center — fuente wideops.com
- Un excelente recurso/checklist son los CIS Benchmarks for Google Cloud: hay benchmarks específicos para Kubernetes y otros sistemas, todos gratuitos.
También existen otras excelentes herramientas de terceros, como Forseti Security y Prisma Cloud de Palo Alto Networks, para escanear y ayudarte a optimizar tus configuraciones y despliegues de código (anteriormente las herramientas Twistlock y Redlock).
Documenta y prueba tus planes de Disaster Recovery y continuidad de negocio
Sobra decirlo, pero debes tener un plan automatizado de respaldo y recuperación de datos para toda tu información, ya esté en buckets o en bases de datos. Conviene practicar el proceso de respaldo y restauración al menos una vez al año, aunque preferiblemente con mayor frecuencia.
Para la continuidad de negocio y tu tranquilidad, se recomienda mucho definir tu infraestructura como código (IaC) usando Terraform. Si tu equipo es disciplinado en mantener el estado de la infraestructura como código, podrás generar fácilmente reportes de auditoría para compliance y recuperarte ante un fallo catastrófico.
Apóyate en expertos que ya lo hayan hecho antes
Apenas he rasguñado la superficie de las consideraciones clave en una transformación cloud empresarial, y puede parecer abrumador, pero lo mejor que puedes hacer es simplemente empezar. Quizás sea parcial, pero la segunda mejor decisión que puedes tomar para aumentar tus probabilidades de éxito es aliarte con profesionales que ya lo hayan hecho muchas veces.
DoiT International ha acompañado a miles de empresas en su camino a la nube con revisiones de arquitectura, soporte experto y herramientas personalizadas de presupuesto y reportes en la nube, todo sin costo adicional para nuestros clientes (somos un partner reseller de cloud). Nuestro objetivo es capacitar y empoderar a tu equipo para que gestione exitosamente tu infraestructura en la nube y, cuando lo necesites, siempre estamos aquí para ayudarte.
¿Quieres más historias de Mike? Visita nuestro blog en Medium o sigue a Mike en Twitter.