mTLS, o TLS mutua, autentica tanto al cliente como al servidor mediante certificados. En el caso de Cuttlefish en Amazon EKS que AWS publicó el 6 de noviembre de 2026, Envoy gestiona el acceso TCP de ADB a los pods; una guía distinta de AWS utiliza NGINX Ingress para verificar certificados de cliente en aplicaciones HTTPS. AWS describe ambas implementaciones.
La diferencia práctica está en el tráfico: Envoy actúa como proxy TCP para ADB dentro de cada namespace (espacio de nombres) de inquilino; NGINX aplica la autenticación de cliente a través de Ingress para una aplicación web.
En el diseño de Envoy, las políticas de red de denegación predeterminada son esenciales: sin ellas, el tráfico puede saltarse el gateway.
Cómo llega ADB a los pods
El usuario inicia la conexión desde una herramienta de línea de comandos. Una API de autorización personalizada valida el JWT, un token que acredita la identidad del usuario, y comprueba a qué namespace tiene acceso. Si la validación es correcta, la API devuelve por HTTPS los datos de conexión y un certificado asociado al namespace. Después, el gateway Envoy de ese namespace dirige el tráfico de ADB únicamente a los pods que contiene.
AWS plantea un gateway por namespace. El aislamiento entre namespaces y los permisos RBAC acotados limitan quién puede acceder a cada entorno. Las políticas NetworkPolicy deben denegar por defecto las conexiones y permitir el acceso al puerto de ADB solo desde el componente previsto. Sin esa restricción, el tráfico puede eludir Envoy.
El certificado identifica el namespace en la conexión mTLS; el JWT identifica al usuario y sus permisos. Para emitir y renovar esos certificados, el diseño combina AWS Private CA con cert-manager y el complemento de emisión de AWS. AWS usa el nombre común <user-namespace>.eks.internal y advierte que ese sufijo no debe entrar en conflicto con el DNS de la organización.
La frontera de mTLS y el ejemplo de NGINX
En el caso de Envoy, mTLS termina en el gateway: el tramo entre Envoy y el pod no queda cifrado mediante mTLS. AWS señala los sidecars o los certificados instalados en los propios pods como opciones para extender esa protección. En la arquitectura descrita, el flujo de ADB tampoco pasa por AWS WAF; la API REST sí está protegida mediante HTTPS y AWS WAF.
La guía de AWS para NGINX configura la verificación del certificado de cliente con anotaciones de Ingress y un Secret de Kubernetes que contiene los certificados del servidor y de la CA. Su prueba espera una respuesta HTTP 400 si el cliente no presenta certificado, y la respuesta de la aplicación cuando sí lo presenta. La guía de NGINX de AWS limita el ejemplo de certificados autofirmados a clústeres de prueba y recomienda AWS Private CA o una PKI existente para producción.
| Aspecto | Envoy Gateway en el caso Cuttlefish | NGINX Ingress en la guía de AWS |
| Tráfico | TCP para acceder a ADB en pods del namespace | HTTPS para aplicaciones detrás de Ingress |
| Función | Proxy Envoy separado por namespace, con acceso limitado mediante políticas de red | Verificación del certificado de cliente mediante anotaciones de Ingress |
| Certificados | AWS Private CA, cert-manager y certificados de ámbito de namespace | La guía muestra certificados autofirmados para pruebas y recomienda una CA privada o una PKI existente en producción |
| Límite de la conexión | mTLS termina en Envoy; el tramo hasta el pod no usa mTLS | El patrón verifica el certificado del cliente en el Ingress de la aplicación |
La elección depende de si necesitas encaminar conexiones TCP de ADB hacia pods o verificar certificados de cliente en una aplicación HTTPS. Son patrones distintos, no dos configuraciones intercambiables para el mismo flujo.
Renovación sin reiniciar Envoy
AWS describe certificados con una vigencia de 12 horas y una ventana de renovación de 4 horas. cert-manager suele iniciar la renovación cuando ha transcurrido dos tercios de la vigencia, es decir, a las 8 horas. Envoy Gateway recibe el certificado renovado desde Kubernetes mediante SDS, el mecanismo de distribución de secretos, sin reiniciar el pod.
El certificado descrito no incluye el identificador del usuario en su sujeto. Por eso, AWS indica que en un namespace compartido por varias personas se necesitan certificados individuales para atribuir cada conexión con mayor detalle.
Los resultados que comunica AWS
Para su despliegue, AWS compara la ruta anterior, basada en un bastion con dos saltos, con el acceso a través de Envoy. Según la empresa, instalar una aplicación antes llevaba entre 3 y 4 minutos y cada ida y vuelta de un comando ADB, entre 1 y 2 segundos. Con Envoy, AWS informa de instalaciones en menos de 30 segundos y comandos ADB que terminan en menos de 100 milisegundos. Por separado, cifra en menos de 50 milisegundos la latencia del gateway frente a una configuración local.
La arquitectura también separa el vídeo de WebRTC del acceso ADB. AWS sustituyó STUNner, que administraba por su cuenta, por Amazon Kinesis Video Streams como retransmisor TURN. La empresa afirma que eliminó un servicio propio de intercambio de credenciales TURN y el mantenimiento manual de servidores TURN; también informa de conexiones estables en horas punta y de que no tuvo que actualizar manualmente las rutas cuando los pods cambiaron de zona de disponibilidad. La facturación de Kinesis Video Streams se calcula según los canales de señalización activos, los mensajes de señalización y los minutos de retransmisión TURN.
