Por qué Kubernetes en sectores regulados no es como Kubernetes en cualquier empresa
Cuando un equipo de plataforma de un banco o una aseguradora propone adoptar Kubernetes, el primer obstáculo no suele ser 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 en formato legible?". La segunda pregunta, del área de riesgos, es igualmente directa: "Si el nodo se cae, o si hay un incidente de seguridad en el runtime, ¿cuánto tiempo tarda en detectarse y cuál es el radio de impacto?".
Kubernetes, en su configuración por defecto, no responde bien a ninguna de las dos. Es una plataforma de orquestación diseñada para la flexibilidad operativa, no para el cumplimiento regulatorio. La respuesta a ambas preguntas depende de cómo se configure, qué herramientas se añaden encima y, de forma no trivial, cuál de los tres managed Kubernetes del mercado cloud se elige como base, porque las capacidades nativas de seguridad, auditoría e integración con servicios regulatorios son significativamente distintas entre AKS, EKS y GKE.
Este artículo parte de proyectos reales en entidades financieras y aseguradoras. No es una comparativa de benchmarks de rendimiento —esos datos cambian con cada versión— sino una guía de las decisiones de arquitectura que determinan si el clúster pasa o no pasa el comité de riesgos, la auditoría interna y el requerimiento regulatorio.
El plano de control: la primera decisión que el arquitecto no puede ignorar
En Kubernetes, el plano de control —el API Server, el Controller Manager, el Scheduler, etcd— es el cerebro del clúster. Quién lo gestiona, dónde reside y qué visibilidad tiene el cliente sobre él es la primera decisión técnica con impacto regulatorio.
Los tres managed Kubernetes gestionan el plano de control por ti: no tienes que parchear el API Server ni gestionar el quorum de etcd. Pero el modelo de propiedad y visibilidad difiere:
AKS (Azure Kubernetes Service) gestiona el plano de control en infraestructura de Microsoft, sin coste adicional. El cliente no tiene acceso directo a etcd ni a los componentes internos del control plane. Los logs del API Server se pueden enviar a Log Analytics Workspace mediante la configuración de Diagnostic Settings. AKS ofrece la opción de private cluster, donde el API Server solo es accesible desde dentro de la red virtual del cliente —sin endpoint público—, un requisito frecuente en entidades bajo ENS Categoría Alta o con políticas de red zero-trust estrictas.
EKS (Elastic Kubernetes Service) sigue un modelo similar: plano de control gestionado por AWS, con la particularidad de que el API Server endpoint puede configurarse como privado, público o dual. Los logs del control plane (API Server, Audit, Authenticator, Controller Manager, Scheduler) se habilitan explícitamente y van a CloudWatch Logs. Un aspecto diferencial: EKS permite elegir la versión de Kubernetes con más granularidad y tiene un ciclo de soporte de versiones más predecible y documentado que AKS.
GKE (Google Kubernetes Engine) tiene el modelo más opaco en cuanto a visibilidad del plano de control para el cliente, pero es también el más maduro en términos de automatización: GKE Autopilot gestiona no solo el plano de control sino también los nodos de trabajo, ofreciendo un modelo serverless de Kubernetes donde el cliente define workloads y Google decide el dimensionamiento. Para entidades que quieren Kubernetes sin equipos de plataforma dedicados, GKE Autopilot es una opción relevante. Para entidades que necesitan control granular del nodo —requisito habitual en cargas de trabajo con restricciones de residencia de datos o perfiles de seguridad muy específicos—, GKE Standard es la alternativa.
El criterio regulatorio: para auditorías bajo DORA, el artículo 28 exige documentar la dependencia con proveedores TIC críticos. Un clúster de Kubernetes gestionado por un hyperscaler es exactamente ese tipo de dependencia. La capacidad de demostrar qué componentes del plano de control gestiona el proveedor, cuáles gestiona la organización, y cuál es el proceso de notificación de incidentes del proveedor sobre esos componentes, es parte de la documentación que el equipo de cumplimiento necesita construir independientemente de qué plataforma se elija.
Clúster privado sin exposición pública: el requisito que llega antes de lo esperado
En la mayoría de proyectos de Kubernetes en entidades financieras y sector público, el requisito de "clúster privado" aparece en la tercera semana, cuando el equipo de seguridad revisa la arquitectura y pregunta: "¿Desde dónde es accesible el API Server?". La respuesta por defecto en los tres managed Kubernetes es: desde internet, a través de un endpoint público con autenticación TLS. Eso es suficiente para muchos contextos, pero no para una entidad bajo ENS Categoría Alta, una entidad financiera con política de zero-trust estricta, o cualquier organización donde el Comité de Seguridad ha definido que los planos de control de infraestructura crítica no pueden tener exposición pública.
El clúster privado resuelve exactamente ese problema: el API Server de Kubernetes solo es accesible desde dentro de la red privada del cliente —VNet, VPC o VPC de Google según el proveedor—, sin ningún endpoint público expuesto a internet. Las implicaciones de esta decisión van más allá de la seguridad: afectan a la conectividad con los pipelines de CI/CD, a la gestión del clúster desde las herramientas de operación del equipo y a la conectividad con sistemas on-premise.
AKS Private Cluster
En AKS, el clúster privado se habilita con el flag --enable-private-cluster en el momento de la creación. Una vez habilitado, el API Server recibe una IP privada dentro de la VNet del cliente y solo es accesible desde esa VNet o desde redes conectadas mediante VNet Peering o ExpressRoute. El FQDN público del API Server desaparece —o se puede mantener como alias privado si así se configura— y no existe ningún endpoint público que atacar.
La integración con la conectividad corporativa en AKS Private Cluster tiene dos patrones habituales: acceso desde on-premise a través de ExpressRoute o VPN Gateway hacia la VNet de AKS, y acceso desde otros servicios Azure mediante Private Endpoints o VNet Peering. Para los pipelines de CI/CD que necesitan hacer kubectl apply contra el clúster —GitHub Actions, Azure DevOps—, la solución estándar es un self-hosted runner desplegado dentro de la VNet de AKS: el runner tiene acceso al API Server privado porque vive en la misma red, y GitHub o Azure DevOps no necesitan acceso directo.
AKS también soporta API Server VNet Integration (disponible en producción desde 2024), un modelo distinto al private cluster clásico: en lugar de usar Private Link, el API Server se inyecta directamente en la VNet del cliente mediante una subred delegada. La ventaja es que elimina la latencia adicional de Private Link y simplifica el modelo de DNS. Para clústeres de producción en entidades con requisitos de latencia muy estrictos entre el plano de control y los nodos, esta opción es relevante.
EKS Private Endpoint
EKS ofrece tres modos de endpoint: público, privado, y dual (público + privado simultáneamente). En modo privado, el API Server solo tiene una IP en la VPC del cliente. El acceso desde on-premise requiere conectividad VPN o Direct Connect hacia la VPC. EKS tiene una particularidad respecto a AKS en modo privado: el plano de control de EKS corre en una VPC gestionada por AWS separada de la VPC del cliente, y la conectividad entre ambas VPCs se establece mediante una ENI (Elastic Network Interface) inyectada en la VPC del cliente. Cuando el endpoint es privado, toda la comunicación entre kubectl y el API Server pasa por esa ENI, sin salir a internet.
Para los pipelines CI/CD en EKS privado, el patrón más común en AWS es usar AWS CodeBuild en VPC como agente de build con acceso a la VPC donde está el ENI del API Server, o un self-hosted runner de GitHub Actions desplegado como pod en Fargate dentro del clúster —patrón que elimina la necesidad de una instancia dedicada de runner y aprovecha el auto-scaling del propio clúster.
GKE Private Cluster
GKE Private Cluster desactiva las IPs públicas tanto del API Server como de los nodos de trabajo. El API Server recibe una IP de una subred reservada configurable, y los nodos solo tienen IPs privadas de la VPC del cliente. GKE añade una capa adicional de control: los Authorized Networks, que permiten restringir qué rangos de IP pueden comunicarse con el API Server incluso dentro de la red privada — útil para entidades que quieren limitar el acceso al plano de control a un subconjunto de subnets de gestión, separadas de las subnets de carga de trabajo.
Una consideración operativa específica de GKE Private Cluster: los nodos sin IP pública necesitan acceso a internet para descargar imágenes de contenedor desde registros públicos y para comunicarse con la API de Google Cloud. La solución estándar es Cloud NAT más el uso de Artifact Registry privado dentro del proyecto GCP del cliente para las imágenes propias. Para entidades que necesitan garantizar que ningún tráfico de los nodos sale a internet bajo ninguna circunstancia, GKE soporta el despliegue sin Cloud NAT si todas las imágenes están en Artifact Registry privado y todos los servicios tienen Private Service Connect configurado.
La trampa operativa que nadie menciona en la documentación oficial: migrar de un clúster público a uno privado es, en los tres proveedores, una operación destructiva: no existe un botón de "convertir a privado" sobre un clúster existente. El cambio requiere crear un clúster nuevo en modo privado, migrar los workloads y redirigir el tráfico. La decisión de clúster privado debe tomarse antes del primer despliegue en producción, no cuando el CISO revisa la arquitectura seis meses después. El cost-of-change de este error específico es consistentemente alto — entre cuatro y ocho semanas de trabajo de replatforming en clústeres de tamaño medio.
Seguridad del runtime: donde las diferencias son más relevantes
El runtime de contenedores es la capa donde el código de la aplicación toca el kernel del nodo. Es también la superficie de ataque más crítica en un clúster Kubernetes: un contenedor comprometido que consigue escapar al nodo puede comprometer todos los workloads que corren en ese nodo. En entidades financieras con cargas de trabajo de distinto nivel de criticidad en el mismo clúster, el aislamiento del runtime es una variable de seguridad que el comité de riesgos TI va a preguntar.
AKS — Kata Containers y nodos confidenciales
AKS soporta Kata Containers como runtime alternativo a containerd: cada pod corre en su propia micro-VM, con un kernel separado del nodo host. El aislamiento es similar al de una máquina virtual tradicional, lo que elimina prácticamente la superficie de escape al nodo. AKS también soporta nodos confidenciales basados en Intel TDX y AMD SEV-SNP, donde la memoria del pod está cifrada y protegida incluso del hypervisor del host. Para cargas de trabajo con datos especialmente sensibles —claves criptográficas, datos de tarjetas, información de salud— esta capacidad no tiene equivalente directo en EKS ni en GKE.
EKS — Fargate y el modelo serverless de aislamiento
EKS resuelve el problema de aislamiento del runtime con un enfoque diferente: AWS Fargate. Cuando un pod se despliega en Fargate, AWS aprovisiona automáticamente una micro-VM dedicada para ese pod específico. El pod nunca comparte infraestructura de kernel con otro pod de otro cliente ni con otro pod del mismo cliente. El modelo es más restrictivo en cuanto a configuración del nodo —no hay acceso al nodo host, no se pueden cargar módulos de kernel— pero a cambio ofrece el aislamiento más fuerte del mercado para workloads serverless. La combinación EKS + Fargate es la opción más común en entidades que quieren Kubernetes sin gestionar nodos y con aislamiento de grado VM por defecto.
GKE — GKE Sandbox y Confidential GKE Nodes
GKE ofrece GKE Sandbox, basado en gVisor: un runtime de contenedores que intercala un kernel de espacio de usuario entre el contenedor y el kernel del nodo, reduciendo significativamente la superficie de syscalls accesibles desde el contenedor. gVisor no ofrece el aislamiento total de Kata o Fargate —es una capa de seguridad adicional, no un hypervisor—, pero tiene un impacto de rendimiento menor y es adecuado para cargas de trabajo de alto volumen donde el aislamiento completo por VM no es viable económicamente. GKE también soporta Confidential GKE Nodes con AMD SEV para cifrado de memoria en el nodo.
Recomendación práctica: para cargas de trabajo multi-tenant dentro del mismo clúster —donde distintas aplicaciones con distintos niveles de criticidad comparten infraestructura—, el modelo de aislamiento debe ser una decisión explícita de arquitectura, no el default del managed Kubernetes elegido. Kata en AKS o Fargate en EKS para pods críticos, runtime estándar para el resto, con Network Policies que segmenten el tráfico entre namespaces.
Identidad y control de acceso: la integración con el directorio corporativo
En sectores regulados, "quién puede hacer qué en el clúster" no es una decisión técnica del equipo de plataforma. Es un requisito de gobierno que el área de seguridad define y que el auditor va a revisar. La integración del clúster Kubernetes con el directorio de identidades corporativo —y la calidad de esa integración— es uno de los criterios de decisión más diferenciadores entre las tres plataformas.
AKS con Microsoft Entra ID tiene la integración más profunda del mercado para organizaciones cuyo directorio corporativo es Microsoft Entra ID — que incluye a la mayoría de grandes empresas españolas. AKS puede configurarse en modo Azure AD-integrated, donde los usuarios se autentican en el API Server con sus credenciales de Entra ID, sin necesidad de gestionar certificados de cliente ni kubeconfig con secretos de larga duración. Los grupos de Entra ID se pueden mapear directamente a ClusterRoleBindings y RoleBindings en Kubernetes, lo que permite que la gestión de accesos al clúster siga el mismo proceso de altas/bajas/modificaciones que el resto de sistemas corporativos. Cuando un empleado abandona la organización y su cuenta de Entra ID se deshabilita, su acceso al clúster se revoca automáticamente.
EKS con AWS IAM tiene una integración sólida con AWS IAM mediante el sistema de autenticación aws-auth y, más recientemente, mediante EKS Pod Identity y EKS Access Entries (disponibles desde 2024), que simplifican la asignación de permisos de Kubernetes a roles IAM sin la complejidad del ConfigMap aws-auth. Para organizaciones cuyo directorio corporativo no es Entra ID o que tienen una estrategia cloud centrada en AWS, el modelo IAM de EKS es robusto y bien documentado. Para organizaciones con Entra ID como directorio principal, la integración requiere una capa adicional (OIDC federation entre Entra ID y EKS) que añade complejidad operativa.
GKE con Google Cloud IAM y Workload Identity resuelve de forma elegante el problema de identidad de los workloads —la identidad que los pods usan para llamar a APIs de Google Cloud— mediante Workload Identity Federation, que asocia una Service Account de Kubernetes a una Service Account de Google Cloud sin necesidad de montar secretos en el pod. Para acceso de usuarios al clúster, GKE se integra con Google Workspace y con Identity Providers externos mediante OIDC. Para organizaciones cuya identidad corporativa es Google Workspace, la experiencia es óptima; para organizaciones con Entra ID, aplica la misma consideración que con EKS.
La regla práctica: el criterio de identidad es frecuentemente el más determinante en la elección de plataforma cuando la organización ya tiene un directorio corporativo consolidado. Si la entidad es Microsoft-first (Entra ID + M365), AKS ofrece la integración más directa con el menor coste operativo de gestión de accesos. Si la entidad tiene una estrategia multi-cloud establecida o es AWS-first, EKS con EKS Access Entries es completamente viable. GKE es la elección natural cuando Google Workspace es el directorio de identidad o cuando la cartera de servicios GCP es la dominante.
Auditoría y observabilidad: lo que el regulador realmente pide
El audit log de Kubernetes registra cada llamada al API Server: quién hizo la llamada, desde dónde, qué recurso afectó y cuál fue el resultado. En un contexto regulado, ese log es evidencia de cumplimiento — no una herramienta de debugging operativo. El equipo de cumplimiento necesita que esos logs se conserven, se envíen al SIEM corporativo y sean consultables con las herramientas que los auditores ya usan.
En AKS, los audit logs del API Server se configuran en Diagnostic Settings y se envían a Log Analytics Workspace o a un Storage Account de Azure para retención a largo plazo. Desde Log Analytics, se pueden crear alertas con Azure Monitor, dashboards en Azure Workbooks o enviar eventos a Microsoft Sentinel para correlación con el resto de señales de seguridad del tenant. Para entidades que ya tienen Sentinel como SIEM, la integración es directa y sin agentes adicionales.
En EKS, los logs del control plane van a CloudWatch Logs. Desde CloudWatch se pueden exportar a S3 para retención a largo plazo, enviar a OpenSearch para análisis, o integrar con el SIEM corporativo mediante Amazon Data Firehose. EKS tiene integración nativa con AWS Security Hub y con Amazon GuardDuty for EKS, que analiza automáticamente los audit logs del clúster en busca de comportamientos anómalos —accesos desde IPs inusuales, escalada de privilegios, creación de recursos fuera de lo normal— sin necesidad de configuración adicional de reglas.
En GKE, los audit logs van a Cloud Audit Logs (parte de Google Cloud Observability). La integración con Security Command Center de Google Cloud ofrece detección automática de misconfiguraciones y vulnerabilidades en el clúster. GKE también se integra con Chronicle (el SIEM de Google) para correlación de seguridad.
Para entidades con SIEM propio (IBM QRadar, Splunk, Microsoft Sentinel en modalidad on-prem extendida), los tres soportan exportación de logs a sistemas externos, pero la facilidad de la integración varía. Sentinel tiene conectores nativos para AKS. Splunk y QRadar tienen integraciones documentadas con los tres, aunque en algunos casos requieren el despliegue de un Forwarder o Collector intermediario.
Networking: segmentación, cifrado y políticas de red en contexto regulado
La red de un clúster Kubernetes en una entidad regulada tiene tres requisitos que van más allá del rendimiento: segmentación entre workloads de distinto nivel de criticidad, cifrado del tráfico entre pods (mTLS), y trazabilidad de los flujos de red para el auditor.
CNI y Network Policies
AKS soporta tres plugins CNI: kubenet (básico, sin Network Policy avanzada), Azure CNI (asigna IPs de la VNet a los pods directamente, requisito frecuente para integración con firewalls de perímetro) y Azure CNI Overlay (escala mejor en clústeres grandes). Para Network Policies avanzadas, AKS integra nativamente Cilium como network policy engine desde 2023, lo que permite políticas L7 basadas en identidad de carga de trabajo — no solo en IP/puerto — con trazabilidad completa a nivel de flujo.
EKS usa el CNI de AWS (amazon-vpc-cni-k8s) por defecto, que asigna IPs de la VPC a los pods, con las mismas implicaciones de integración con Security Groups. Los Security Groups de AWS son aplicables a pods individuales mediante Security Groups for Pods, lo que permite aplicar las mismas políticas de red que la entidad ya tiene definidas en AWS para sus recursos EC2, sin aprender un nuevo modelo. Para Network Policies de Kubernetes estándar, EKS soporta Calico y Cilium como addons.
GKE usa su propio CNI (GKE Dataplane V2), basado en Cilium, habilitado por defecto en clústeres nuevos desde 2022. Ofrece Network Policies nativas de Kubernetes más un conjunto de Network Policy logging que registra qué conexiones fueron permitidas y denegadas — dato útil para auditorías. GKE también soporta Hierarchical Namespaces con políticas de red heredadas, lo que facilita la segmentación en clústeres multi-tenant.
mTLS entre servicios
Ninguno de los tres managed Kubernetes activa mTLS entre pods por defecto. Para entidades que necesitan cifrado de tráfico este-oeste — requisito cada vez más frecuente en auditorías bajo DORA y en implementaciones Zero Trust — la respuesta habitual es un service mesh. Istio es la opción más madura y está soportada nativamente en GKE (GKE Managed Service Mesh) y en AKS (a través de Azure Service Mesh, basado en Istio). En EKS, AWS ofrece AWS App Mesh (basado en Envoy) y soporte para Istio como instalación independiente. La tendencia del mercado apunta claramente hacia Istio como estándar de facto en enterprise.
Gestión de versiones y parches: el riesgo que los equipos subestiman
Kubernetes publica tres releases menores al año. Cada versión tiene soporte durante aproximadamente catorce meses. Pasado ese período, la versión está fuera de soporte y no recibirá parches de seguridad. En una entidad regulada, correr una versión de Kubernetes fuera de soporte es un hallazgo de auditoría de primer nivel — exactamente el mismo que correr Windows Server 2008 en producción.
AKS tiene auto-upgrade channels: el arquitecto configura el canal (patch, stable, rapid, node-image) y AKS actualiza automáticamente el clúster dentro de una ventana de mantenimiento configurable. Para entidades con ventanas de cambio controladas — requisito habitual en banca con procesos CAB formales —, la configuración de la ventana de mantenimiento y la posibilidad de pausar las actualizaciones automáticas es un punto de control disponible. AKS también soporta blue-green upgrades mediante node pool swap para actualizar los nodos sin downtime.
EKS no actualiza automáticamente los nodos de trabajo por defecto: la actualización del plano de control y de los nodos son operaciones separadas que el equipo debe ejecutar. Esto da más control pero requiere más disciplina operativa. AWS anuncia el fin de soporte de cada versión con al menos doce meses de antelación, lo que facilita la planificación del calendario de actualizaciones. EKS también ofrece EKS Extended Support, que extiende el soporte de versiones fuera de ciclo estándar por un coste adicional — útil para entidades con procesos de cambio lentos.
GKE tiene el modelo de actualización más automatizado de los tres: los release channels (Rapid, Regular, Stable) actualizan tanto el plano de control como los nodos automáticamente dentro de ventanas configurables. GKE también tiene la capacidad de surge upgrades y blue-green upgrades para minimizar la interrupción durante las actualizaciones. Para equipos con recursos limitados para gestión de plataforma, el nivel de automatización de GKE reduce la carga operativa de mantener el clúster en versión soportada.
Azure Arc: gestión unificada cuando la respuesta no es un único clúster
La realidad de las organizaciones medianas y grandes en sectores regulados no es un único clúster Kubernetes en un único proveedor cloud. Es tres clústeres AKS para aplicaciones Microsoft-first, dos clústeres EKS donde vive la plataforma de datos, un clúster on-premise en el centro de datos corporativo para cargas que no pueden salir del perímetro físico, y quizás un clúster GKE heredado de una adquisición o de un proyecto de IA en Vertex AI. La pregunta que nadie responde bien en las comparativas de plataformas es: ¿cómo se gestiona todo eso de forma coherente?
Azure Arc for Kubernetes es la respuesta de Microsoft a ese problema. Permite proyectar el plano de gestión de Azure —políticas, RBAC, GitOps, monitorización, seguridad— sobre cualquier clúster Kubernetes, independientemente de dónde corra: AKS, EKS, GKE, clústeres on-premise (OpenShift, Rancher, k3s), o clústeres en el edge. El clúster no necesita estar en Azure para ser gestionado como si lo estuviera.
Cómo funciona Arc for Kubernetes
La incorporación de un clúster a Azure Arc se hace desplegando un conjunto de agentes de Arc en el clúster —en el namespace azure-arc— que establecen una conexión saliente hacia Azure Resource Manager. No se abre ningún puerto entrante en el clúster: la conexión es siempre iniciada desde los agentes hacia Azure, lo que hace el modelo compatible con clústeres privados sin endpoint público. Una vez conectado, el clúster aparece como un recurso de Azure Resource Manager con su propio Resource Group, sus propias etiquetas y su propia gestión de RBAC de Azure.
Desde ese momento, el equipo de plataforma puede aplicar al clúster Arc-conectado las mismas herramientas que usa para gestionar clústeres AKS nativos:
- Azure Policy for Kubernetes: aplica políticas de OPA/Gatekeeper sobre todos los clústeres conectados desde una única definición central. Una política que prohíbe contenedores con privilegios de root se define una vez en Azure Policy y se aplica simultáneamente al clúster AKS de producción, al clúster EKS de datos y al clúster on-premise del centro de datos corporativo.
- GitOps con Flux: Arc gestiona el estado de los clústeres conectados mediante GitOps (operador Flux integrado). El repositorio Git es la fuente de verdad de las configuraciones y manifiestos de Kubernetes; Arc sincroniza el estado deseado del repositorio con el estado real de cada clúster, sin necesidad de acceso directo al API Server desde los pipelines CI/CD.
- Microsoft Defender for Containers: cubre los clústeres Arc-conectados con la misma detección de amenazas en runtime, análisis de vulnerabilidades en imágenes y posture management que protege a los clústeres AKS nativos. El CISO tiene una única consola de Defender for Cloud con visibilidad de todos los clústeres, independientemente del proveedor donde corran.
- Azure Monitor y Container Insights: recoge métricas y logs de los clústeres Arc-conectados hacia el mismo Log Analytics Workspace que centraliza la observabilidad del resto de recursos Azure. Sentinel recibe los eventos de seguridad de todos los clústeres en el mismo pipeline que el resto de señales del tenant.
El valor regulatorio de Arc en una arquitectura multiclúster
Para una entidad bajo DORA, el artículo 28 exige documentar las dependencias con proveedores TIC críticos. En una arquitectura con clústeres en tres proveedores distintos, esa documentación requiere tres inventarios de gestión de dependencias separados, tres procesos de notificación de incidentes distintos y tres conjuntos de evidencias de cumplimiento para la auditoría. Con Arc, el inventario de todos los clústeres vive en Azure Resource Manager como un único grafo de recursos. Las políticas de seguridad son las mismas definiciones aplicadas desde Azure Policy. Los logs de auditoría de todos los clústeres van al mismo Log Analytics Workspace. La evidencia de cumplimiento para el auditor es coherente y centralizada.
Cuándo Arc es la respuesta correcta y cuándo no lo es
Arc for Kubernetes es la elección adecuada cuando la organización ya tiene Azure como plataforma de gestión de referencia (o está dispuesta a adoptarla para ese rol), cuando el portfolio de clústeres es heterogéneo por razones técnicas o históricas, y cuando la consolidación del plano de control y cumplimiento tiene más valor que la pureza de un modelo single-cloud.
No es la elección correcta cuando la organización quiere independencia completa de todos los planos de control de los hyperscalers —en ese caso, herramientas como Rancher Fleet, Crossplane o Anthos Config Management de Google son alternativas que no tienen dependencia de Azure—. Tampoco es la elección más eficiente para organizaciones que ya están 100% en un único proveedor y no tienen planes de cambiar: en ese caso, las herramientas nativas del proveedor (Azure Policy + Defender para AKS; AWS Organizations + GuardDuty para EKS; GKE Config Controller + SCC para GKE) cubren el caso de uso sin la capa adicional de Arc.
Para la mayoría de entidades financieras y aseguradoras con presencia multicloud que conocemos, Arc representa el menor coste de implementación de un plano de gestión y cumplimiento unificado, especialmente cuando Microsoft Sentinel ya es el SIEM de referencia: la integración de todos los clústeres en Sentinel a través de Arc es una configuración, no un proyecto de integración.
Arquitectura de referencia: clúster privado multiclúster con Arc
El siguiente diagrama muestra una arquitectura de referencia genérica para una entidad con clústeres en AKS (Microsoft-first), EKS (plataforma de datos AWS) y un clúster on-premise (cargas no exportables), gestionados de forma unificada con Azure Arc. Es un patrón anónimo extraído de proyectos reales.
El diagrama refleja los principios que determinan si la arquitectura pasa o no pasa el comité de seguridad en una entidad regulada: ningún API Server con endpoint público, conectividad on-premise mediante ExpressRoute o Direct Connect sin VPN compartida, plano de observabilidad unificado en Log Analytics y Sentinel independientemente del proveedor donde corra el clúster, y agentes Arc con conexión exclusivamente saliente desde los clústeres hacia Azure.
La tabla de decisión — los criterios que importan en sectores regulados
| Criterio | AKS (Azure) | EKS (AWS) | GKE (Google) |
|---|---|---|---|
| Integración con directorio corporativo | ⭐⭐⭐ Nativa con Entra ID. Grupos de AD mapeados a RBAC sin capa adicional. | ⭐⭐ Sólida con IAM. Integración con Entra ID requiere OIDC federation. | ⭐⭐ Nativa con Google Workspace. Entra ID requiere configuración adicional. |
| Aislamiento del runtime | ⭐⭐⭐ Kata Containers + nodos confidenciales Intel TDX/AMD SEV-SNP. | ⭐⭐⭐ Fargate: micro-VM dedicada por pod, sin gestión de nodos. | ⭐⭐ GKE Sandbox (gVisor) + Confidential Nodes AMD SEV. Sin hypervisor por pod en modo standard. |
| Audit logging y SIEM | ⭐⭐⭐ Integración nativa con Sentinel. Diagnostic Settings a Log Analytics. | ⭐⭐⭐ CloudWatch + GuardDuty for EKS. Integración con Splunk/QRadar bien documentada. | ⭐⭐ Cloud Audit Logs + SCC. Integración con Chronicle. Conectores a SIEM externos menos maduros. |
| Networking y segmentación | ⭐⭐⭐ Azure CNI + Cilium nativo. Integración con Azure Firewall y NSG. | ⭐⭐⭐ VPC CNI + Security Groups for Pods. Modelo de red AWS familiar para equipos AWS. | ⭐⭐⭐ GKE Dataplane V2 (Cilium). Network Policy logging integrado. |
| mTLS / Service Mesh | ⭐⭐⭐ Azure Service Mesh (Istio gestionado) nativo. | ⭐⭐ App Mesh + Istio autogestionado. Menos integrado que AKS o GKE. | ⭐⭐⭐ GKE Managed Service Mesh (Istio gestionado) nativo. |
| Gestión de versiones y parches | ⭐⭐ Auto-upgrade channels con ventanas configurables. Control CAB posible. | ⭐⭐⭐ Control manual de nodos + Extended Support para entidades con ciclos lentos. | ⭐⭐⭐ Release channels con automatización completa. Menor carga operativa. |
| FinOps y visibilidad de costes | ⭐⭐ Azure Cost Management. Coste del plano de control gratuito. | ⭐⭐ AWS Cost Explorer. Coste del plano de control: ~0,10$/hora por clúster. | ⭐⭐⭐ GKE Autopilot: modelo serverless con facturación por pod. Más predecible a escala. |
| Clúster privado (sin endpoint público) | ⭐⭐⭐ Private Cluster nativo + API Server VNet Integration. Compatible con ENS Categoría Alta. | ⭐⭐⭐ Endpoint privado configurable. ENI en VPC del cliente. Compatible con Fargate privado. | ⭐⭐⭐ Private Cluster disponible. Authorized Networks para restricción adicional por subred. |
| Gestión multiclúster / multiplataforma | ⭐⭐⭐ Azure Arc nativo: gestiona AKS, EKS, GKE y on-premise desde Azure Policy + Flux + Sentinel. | ⭐⭐ EKS Connector para Arc. AWS Systems Manager para on-premise. Menos maduro que Arc. | ⭐⭐ Anthos Config Management para GKE + on-premise. No cubre AKS/EKS de forma nativa. |
| Modelo de soporte y SLA regulatorio | ⭐⭐⭐ SLA 99,95% con zonas de disponibilidad. Cobertura ENS y DORA documentada. | ⭐⭐⭐ SLA 99,95% con multi-AZ. AWS Artifact para documentación de cumplimiento. | ⭐⭐⭐ SLA 99,95% con zonas. Google Cloud Compliance Reports Manager. |
Los casos de uso que determinan la elección en la práctica
Caso 1: Clúster para microservicios de negocio en una entidad Microsoft-first
Una entidad financiera que tiene Azure como nube principal, Entra ID como directorio, Microsoft Sentinel como SIEM y Microsoft Defender for Cloud como plataforma de seguridad cloud. El clúster va a alojar los microservicios que implementan la lógica de negocio: originación de créditos, gestión de expedientes, motores de reglas.
La elección es AKS. La integración de Entra ID con el RBAC del clúster elimina una capa completa de gestión de identidades. Defender for Containers cubre el análisis de vulnerabilidades en imágenes, la detección de amenazas en runtime y el posture management del clúster con cero configuración adicional. Los audit logs van a Sentinel directamente. El equipo de seguridad trabaja con las mismas herramientas que usa para el resto del tenant Azure.
Caso 2: Plataforma de datos y ML en una entidad con estrategia multicloud
Una aseguradora que tiene workloads en AWS y Azure, con la plataforma de datos sobre AWS (S3, Redshift, SageMaker). El clúster va a alojar pipelines de datos, modelos de ML en inferencia y APIs de scoring.
La elección habitual es EKS. Los pods de scoring necesitan acceder a S3 y a SageMaker endpoints: la integración con IAM mediante EKS Pod Identity elimina la gestión de credenciales de larga duración. Fargate para los pods de inferencia proporciona aislamiento de runtime sin gestión de nodos. La facturación del consumo de recursos AWS se consolida en la misma factura que el resto de servicios AWS de la entidad.
Caso 3: Plataforma de servicios digitales con equipo de plataforma pequeño
Una entidad mediana (banca cooperativa, mutua aseguradora) que quiere Kubernetes para sus aplicaciones digitales pero no tiene un equipo de plataforma dedicado para gestionar nodos, actualizaciones y capacidad.
GKE Autopilot es la opción más directa. El equipo define los pods y sus recursos solicitados; Google gestiona los nodos, las actualizaciones, la capacidad y la distribución entre zonas. La facturación es por pod-hora de CPU y memoria solicitados, lo que hace el coste más predecible que en un modelo de nodos fijos.
Caso 4: Clúster para cargas de trabajo con requisitos de soberanía de datos estrictos
Un organismo de la Administración Pública bajo ENS Categoría Alta, o una entidad con datos que no pueden salir de infraestructura con garantías contractuales específicas de residencia en España.
Los tres hyperscalers tienen regiones en España (Azure: Spain Central en Madrid; AWS: España; Google Cloud: Madrid). Para ENS Categoría Alta con requisitos de acceso físico controlado y auditoría de proveedor, AKS sobre Azure Dedicated Host o EKS sobre instancias EC2 dedicadas son las opciones que más fácilmente documentan el aislamiento físico que el esquema exige.
Lo que el arquitecto no puede delegar al managed Kubernetes
Elegir AKS, EKS o GKE resuelve la gestión del plano de control y simplifica la operación de los nodos. No resuelve automáticamente ninguna de estas cuatro áreas, que siguen siendo responsabilidad del equipo:
Hardening del clúster. Los tres managed Kubernetes tienen configuraciones por defecto que priorizan la facilidad de uso sobre la seguridad. Pod Security Admission, restricción de capacidades de Linux en los contenedores, bloqueo del acceso al metadata endpoint del nodo desde los pods, desactivación de ServiceAccount token automounting para pods que no lo necesitan: ninguna de estas configuraciones viene activada por defecto y todas son relevantes para una auditoría de seguridad.
Gestión de secretos. Kubernetes tiene un mecanismo de Secrets nativo, pero almacena los valores en etcd cifrado con una clave gestionada por el proveedor cloud por defecto. En entidades reguladas que necesitan gestión de claves con HSM o con control sobre el ciclo de vida de las claves de cifrado, la integración con Azure Key Vault (AKS), AWS Secrets Manager/KMS (EKS) o Google Secret Manager/Cloud KMS (GKE) mediante el CSI Secrets Store Driver es un componente de arquitectura que el equipo debe diseñar e implementar explícitamente.
Política de imágenes. Un clúster Kubernetes puede ejecutar cualquier imagen de contenedor accesible desde los nodos a menos que se configure explícitamente una política de admisión que lo restrinja. En una entidad regulada, la procedencia de las imágenes —registro privado de la organización con escaneo de vulnerabilidades previo— es un control de seguridad que el auditor va a revisar. Esto requiere configurar un Admission Webhook (Kyverno o Gatekeeper) que rechace imágenes que no provengan del registro autorizado o que no hayan pasado el escaneo de vulnerabilidades.
Disaster Recovery y RTO/RPO. El SLA del 99,95% de los tres managed Kubernetes cubre la disponibilidad del API Server. No cubre la disponibilidad de las aplicaciones que corren en el clúster ni el tiempo de recuperación ante un fallo de zona o región. El diseño de la topología multi-zona, la estrategia de replicación de stateful sets, el proceso de failover a un clúster de DR y el RTO/RPO documentado son responsabilidad del arquitecto de solución, no del managed Kubernetes.
Resumen ejecutivo — para el comité que tiene que decidir
La elección entre AKS, EKS y GKE en un sector regulado no es una decisión puramente técnica. Es una decisión que combina el ecosistema cloud existente, el modelo de identidad corporativo, los requisitos de trazabilidad del regulador y la capacidad del equipo de plataforma para operar la solución a largo plazo.
Decisión transversal previa: independientemente del proveedor elegido, el clúster privado sin endpoint público es el punto de partida correcto para cualquier entidad regulada. No es una opción avanzada — es el baseline. Y es una decisión que debe tomarse antes del primer despliegue en producción, porque migrar un clúster público a privado en los tres proveedores es una operación destructiva que requiere recrear el clúster desde cero.
AKS es la elección con menor fricción para entidades Microsoft-first: la integración con Entra ID, Sentinel, Defender for Cloud y Azure Policy crea un stack de seguridad y cumplimiento coherente que el equipo de seguridad ya conoce. Los nodos confidenciales son la opción más avanzada del mercado para cargas de trabajo con requisitos de protección de datos en uso. Y Azure Arc convierte a AKS en el hub natural de un plano de gestión multiclúster que cubre EKS, GKE y on-premise desde una única consola.
EKS es la elección natural para entidades con estrategia AWS establecida, especialmente cuando los workloads de Kubernetes necesitan integración profunda con servicios AWS de datos (S3, Redshift, SageMaker). Fargate ofrece el modelo de aislamiento de runtime más robusto para cargas serverless. El Extended Support de versiones es una válvula de seguridad para entidades con procesos de cambio lentos.
GKE es la opción con mayor automatización operativa, especialmente en modo Autopilot, y la más adecuada para equipos con recursos limitados de gestión de plataforma. El modelo de red basado en Cilium con logging de flujos está más integrado por defecto que en los competidores. Para entidades con Google Workspace como directorio de identidad o con workloads de IA/ML en Vertex AI, la integración de GKE con el ecosistema Google Cloud es el argumento más directo.
Para arquitecturas multiclúster heterogéneas — que es la realidad de la mayoría de organizaciones medianas y grandes — Azure Arc es el plano de gestión con mayor madurez del mercado para unificar política, GitOps, observabilidad y seguridad sobre clústeres en cualquier proveedor. No es el único modelo posible, pero sí el que menor coste de implementación tiene cuando Microsoft Sentinel ya es el SIEM de referencia de la organización.
Lo que los tres comparten: ninguno es una decisión incorrecta si el equipo entiende sus capacidades y sus límites, si el clúster privado está diseñado desde el día uno, si el hardening posterior está planificado desde el inicio, y si la elección de plataforma está alineada con el ecosistema cloud donde la entidad ya tiene las competencias, los contratos y las integraciones de seguridad construidas.