Introducción
Los equipos de plataforma que gestionan clústeres Amazon Elastic Kubernetes Service (Amazon EKS) multi-tenant enfrentan un dilema persistente: cómo asegurar protocolos heredados o especializados como Android Debug Bridge (ADB) y Web Real-Time Communication (WebRTC). De fábrica, estos protocolos carecen de cifrado en tránsito y no integran mecanismos de autenticación empresarial estándar como JSON Web Tokens (JWTs). En un entorno compartido donde los pods de distintos inquilinos coexisten, la exposición por defecto permite que cualquier pod alcance los puertos abiertos de otro, salvo que se implementen NetworkPolicies estrictas.
El problema real no es solo la vulnerabilidad del canal, sino la inviabilidad técnica de parchear cada protocolo individualmente a escala. Modificar el código fuente de servicios como Cuttlefish (dispositivo virtual Android de Google) para añadir TLS o JWTs genera deuda técnica y divergencia del upstream. La solución sostenible requiere una capa de infraestructura que abstracta la seguridad, separando la lógica de negocio del protocolo de su mecanismo de confianza.
Qué ocurrió
AWS documentó en un análisis reciente cómo las arquitecturas tradicionales para acceder a servicios no HTTP en EKS dependían de bastion hosts y port-forwarding a través de la API del servidor Kubernetes. Este patrón, aunque común, introduce cuellos de botella de rendimiento y fragilidad operativa. Al enrutar todo el tráfico a través de la API del control plane, las sesiones concurrentes saturan los recursos de gestión, independientemente de que el clúster subyacente permanezca privado.
Paralelamente, la implementación de servidores TURN (Traversal Using Relays around NAT) para WebRTC mediante soluciones open-source como STUNner reveló desafíos críticos de integración. STUNner no poseía integración nativa con los servicios AWS ni con el Identity Provider (IdP) empresarial, lo que obligaba a construir servicios customizados para intercambiar tokens. A medida que crecía la carga, el mantenimiento manual de reglas de enrutamiento durante migraciones de pods entre Availability Zones y las caídas de conexiones en picos de uso se volvieron inmanejables.
La arquitectura resultante identifica tres componentes reutilizables que sustituyen este modelo frágil: gateways Envoy con alcance a nivel de namespace para mTLS, relays TURN gestionados vía Amazon Kinesis Video Streams y cadenas de identidad JWT vinculadas al IdP corporativo. Este enfoque elimina la dependencia de parches customizados en el código de la aplicación, desplazando las responsabilidades de seguridad a la infraestructura declarativa de Kubernetes.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de SRE y Seguridad, la adopción de mTLS (mutual TLS) a nivel de gateway reduce la superficie de ataque significativa en entornos multi-tenant. Al exigir que tanto el cliente como el servidor presenten certificados válidos emitidos por una autoridad privada confiable, se elimina la necesidad de confiar únicamente en la red IP o en secretos estáticos dentro del pod. Esto es crucial para protocolos como ADB y VNC, donde las credenciales son locales al protocolo y no tienen integración nativa con almacenes de identidad centralizados como AWS IAM o Azure AD.
Desde la perspectiva operativa, la sustitución de servidores TURN autogestionados por servicios gestionados como Amazon Kinesis Video Streams reduce la carga administrativa. Los equipos dejan de invertir tiempo en parchear binarios de STUN/TURN, monitorear escalado manual y resolver conflictos de red durante las migraciones de nodos. La automatización del ciclo de vida de los certificados mediante cert-manager y AWS Private Certificate Authority (AWS Private CA) asegura que la rotación de credenciales ocurra sin intervención humana, minimizando el riesgo de errores humanos en la renovación manual.
Además, la trazabilidad mejora drásticamente. Al vincular cada identidad JWT con un RoleSessionName en AWS Security Token Service (STS), cada llamada a la API queda registrada en los logs de auditoría asociada a una persona específica. En entornos de cumplimiento normativo estricto, esta capacidad de correlación entre una sesión de desarrollo ad-hoc y un registro auditable es un control de seguridad fundamental que las arquitecturas de bastion host tradicionales dificultan.
Detalles técnicos
La implementación se apoya en Envoy Gateway como proxy TCP para tráfico no HTTP. Cada namespace ejecuta su propia instancia de Envoy Gateway, configurada para enrutar el tráfico exclusivamente hacia los pods dentro de ese mismo namespace. La autenticación se verifica durante el handshake mTLS mediante la validación del campo commonName (CN) del certificado del cliente, que sigue la convención <user-namespace>.eks.internal. Este sufijo interno evita conflictos con el DNS corporativo y permite a Envoy validar que el cliente pertenece al namespace esperado.
La gestión de certificados recae en cert-manager utilizando el plugin emisor de AWS Private CA. Se emplea un AWSPCAClusterIssuer a nivel de clúster, en lugar de emisores por namespace, para centralizar la configuración de la Autoridad de Certificación y evitar la duplicación de recursos. Los certificados emitidos tienen una vida útil corta de 12 horas en producción. Esta estrategia de «short-lived certificates» mitiga el riesgo de compromiso sin requerir infraestructura compleja de revocación como CRL (Certificate Revocation List) o OCSP.
El ciclo de renovación se configura para iniciar automáticamente cuando el certificado alcanza dos tercios de su vida útil (aproximadamente a las 8 horas), proporcionando una ventana de 4 horas para reintentos antes de la expiración. Envoy Gateway recarga el nuevo certificado sin reiniciar el proxy, garantizando disponibilidad continua. Para WebRTC, aunque el medio se cifra con DTLS/SRTP, la señalización queda expuesta si no se protege la capa de control; la arquitectura actual mantiene el servidor de señalización por defecto de Cuttlefish pero termina TLS en el endpoint y valida sesiones mediante JWTs a nivel de aplicación.
# Ejemplo conceptual de configuración de certificado para mTLS
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: gateway-mtls-cert
spec:
secretName: mtls-gateway-secret
duration: 12h # Vida útil corta para reducir riesgo
renewBefore: 4h # Ventana de renovación anticipada
commonName: tenant-a.eks.internal
usages:
- client auth
- server authQué deberían hacer los administradores y equipos técnicos
Primero, auditen sus clústeres EKS actuales para identificar servicios expuestos mediante protocolos no HTTP que carezcan de NetworkPolicies estrictas. Si utilizan ADB, VNC o puertos TCP personalizados compartidos entre tenants, asuman una postura de «default-deny» antes de desplegar cualquier nuevo componente de seguridad. La aplicación de NetworkPolicies debe preceder a la emisión de certificados y al despliegue del gateway para evitar ventanas de exposición transitorias.
Segundo, evalúen la viabilidad de implementar Envoy Gateway junto con cert-manager y AWS Private CA en un namespace piloto. No intenten migrar todos los servicios simultáneamente. Comiencen configurando el AWSPCAClusterIssuer y validen que cert-manager puede emitir y renovar certificados automáticamente con la duración propuesta de 12 horas. Verifiquen que Envoy Gateway puede cargar dinámicamente los secretos rotados sin interrumpir las sesiones TCP activas, un punto crítico para servicios como ADB donde la reconexión manual es costosa.
Finalmente, para cargas de trabajo WebRTC intensivas, consideren migrar del servidor TURN autogestionado a Amazon Kinesis Video Streams o una alternativa gestionada similar si su stack lo permite. Si deben mantener STUNner o soluciones similares, implementen un servicio de intercambio de tokens que convierta los JWTs del IdP empresarial en credenciales TURN con tiempo de vida limitado y alcance restringido al namespace. Esto previene el uso indebido de credenciales compartidas entre tenants distintos y facilita la auditoría de las conexiones multimedia.
Conclusión
La seguridad en Kubernetes multi-tenant no se logra parcheando cada aplicación, sino definiendo estándares de infraestructura que los protocolos heredados puedan respetar sin modificarse. La combinación de Envoy Gateway para mTLS, AWS Private CA para gestión de identidades y políticas de red estrictas crea un perímetro robusto alrededor de servicios como ADB y WebRTC.
Esta arquitectura desplaza la complejidad desde el código de la aplicación hacia una capa de plataforma estandarizada y automatizada. Para los equipos DevOps, esto significa menos deuda técnica en forks de software open-source y una postura de seguridad más auditable y escalable. La clave reside en aceptar que la confianza se establece mediante certificados efímeros validados por una CA privada, no mediante la obscuridad de la red o la configuración manual de puertos.
Fuentes
https://aws.amazon.com/blogs/security/addressing-protocol-security-gaps-in-multi-tenant-kubernetes/