Por qué Kubernetes en sectores regulados no es como en cualquier empresa
Cuando un equipo de plataforma de un banco o una aseguradora propone Kubernetes, el primer obstáculo no es técnico. Es la pregunta del CISO: «¿Cómo sé quién hizo qué, cuándo, sobre qué contenedor, con qué privilegios, y puedo demostrárselo al auditor?». La segunda, del área de riesgos: «Si hay un incidente en el runtime, ¿cuánto tarda en detectarse y cuál es el radio de impacto?». Kubernetes, por defecto, no responde bien a ninguna de las dos: es una plataforma de orquestación diseñada para la flexibilidad, no para el cumplimiento. La respuesta depende de la configuración, las herramientas que se añaden encima y cuál de los tres managed Kubernetes se elige como base.
El plano de control: la primera decisión con impacto regulatorio
Los tres gestionan el plano de control por ti, pero el modelo de propiedad y visibilidad difiere. AKS lo gestiona sin coste adicional y ofrece private cluster, donde el API Server solo es accesible desde la VNet del cliente. EKS permite endpoint privado, público o dual, con logs del control plane a CloudWatch y granularidad de versión más predecible. GKE es el más opaco en visibilidad pero el más maduro en automatización, con Autopilot gestionando también los nodos. Para auditorías DORA, el artículo 28 exige documentar la dependencia con proveedores TIC críticos, y un clúster gestionado por un hyperscaler es exactamente ese tipo de dependencia.
Clúster privado sin exposición pública: el requisito que llega antes de lo esperado
En la mayoría de proyectos, el requisito de «clúster privado» aparece en la tercera semana, cuando seguridad pregunta desde dónde es accesible el API Server. El clúster privado hace que el API Server solo sea accesible desde la red privada del cliente, sin endpoint público. AKS lo habilita con --enable-private-cluster y soporta también API Server VNet Integration. EKS ofrece endpoint privado mediante una ENI inyectada en la VPC del cliente. GKE Private Cluster desactiva las IPs públicas de API Server y nodos y añade Authorized Networks. La trampa que pocas veces se explicita es que migrar de un clúster público a uno privado es, en los tres casos, una operación destructiva. La decisión debe tomarse antes del primer despliegue en producción, porque el cost-of-change suele traducirse en cuatro a ocho semanas de replatforming.
Seguridad del runtime: donde las diferencias son más relevantes
El runtime es la superficie de ataque más crítica: si un contenedor escapa al nodo, puede comprometer todos los workloads que se ejecutan en él. AKS soporta Kata Containers, con una micro-VM por pod, y nodos confidenciales Intel TDX/AMD SEV-SNP con memoria cifrada, sin equivalente directo en los otros. EKS resuelve el aislamiento con Fargate, que aprovisiona una micro-VM dedicada por pod. GKE ofrece GKE Sandbox, basado en gVisor, con menor impacto de rendimiento pero sin aislamiento total por VM, además de Confidential GKE Nodes. Para cargas multi-tenant en el mismo clúster, el modelo de aislamiento debe ser una decisión explícita de arquitectura, no una configuración por defecto.
Identidad y control de acceso: la integración con el directorio corporativo
En sectores regulados, «quién puede hacer qué en el clúster» es un requisito de gobierno que el auditor revisa con detalle. AKS con Microsoft Entra ID tiene la integración más profunda: grupos de Entra mapeados a RBAC sin capa adicional y revocación automática al deshabilitar la cuenta. EKS con AWS IAM, EKS Pod Identity y Access Entries desde 2024 es sólido para entornos AWS-first; con Entra ID requiere OIDC federation. GKE con Workload Identity Federation resuelve bien la identidad de los workloads y se integra con Google Workspace. El criterio de identidad suele ser uno de los más determinantes cuando la organización ya cuenta con un directorio corporativo consolidado.
Auditoría y observabilidad: lo que el regulador realmente pide
El audit log de Kubernetes registra cada llamada al API Server; en un contexto regulado es evidencia de cumplimiento, no debugging. En AKS los audit logs van a Log Analytics y a Sentinel sin agentes adicionales. En EKS van a CloudWatch, con integración nativa con Security Hub y GuardDuty for EKS. En GKE van a Cloud Audit Logs, con Security Command Center y Chronicle. Para entidades con SIEM propio (QRadar, Splunk, Sentinel), los tres soportan exportación, pero la facilidad varía: Sentinel tiene conectores nativos para AKS.
Azure Arc: gestión unificada cuando la respuesta no es un único clúster
La realidad de las organizaciones medianas y grandes no suele ser un único clúster en un único proveedor. Lo habitual es encontrar AKS para aplicaciones Microsoft-first, EKS para la plataforma de datos, un clúster on-premise para cargas que no se pueden mover fuera del entorno propio y, en algunos casos, algún GKE heredado. Azure Arc for Kubernetes proyecta el plano de gestión de Azure, incluidas políticas, RBAC, GitOps, monitorización y seguridad, sobre cualquier clúster, se ejecute donde se ejecute. La incorporación despliega agentes en el namespace azure-arc con conexión saliente hacia Azure Resource Manager, sin abrir puertos entrantes, lo que lo hace compatible con clústeres privados.
Una vez conectado, se aplican las mismas herramientas que a un AKS nativo: Azure Policy for Kubernetes, OPA/Gatekeeper desde una definición central, GitOps con Flux, Microsoft Defender for Containers y Azure Monitor con Container Insights hacia el mismo Log Analytics. Para una entidad bajo DORA, el inventario de todos los clústeres vive en Azure Resource Manager como un único grafo, las políticas comparten las mismas definiciones y los logs llegan al mismo workspace. La evidencia de cumplimiento queda así más coherente y centralizada. Arc no es la elección correcta cuando la organización busca independencia total de los planos de control de los hyperscalers, ni cuando está 100% en un único proveedor.
Resumen ejecutivo para el comité que tiene que decidir
Hay una decisión transversal que conviene tomar antes de elegir proveedor: para cualquier entidad regulada, el clúster privado sin endpoint público debería ser el punto de partida y debe definirse antes del primer despliegue. AKS es la opción con menor fricción para entidades Microsoft-first: Entra ID, Sentinel, Defender for Cloud y Azure Policy forman un stack coherente, y Arc convierte AKS en el hub de gestión multiclúster. EKS encaja de forma natural en estrategias AWS, especialmente cuando hay una integración fuerte con S3, Redshift y SageMaker; Fargate aporta además un modelo de aislamiento muy robusto. GKE destaca por su automatización operativa, especialmente útil para equipos con recursos limitados. Para arquitecturas multiclúster heterogéneas, que son la realidad de muchas organizaciones, Azure Arc es el plano de gestión con mayor madurez, sobre todo cuando Sentinel ya es el SIEM de referencia.
