¿Cómo se autentican los servicios entre sí en una malla de microservicios — mTLS vs. cuentas de servicio/tokens?

#Por qué importa la identidad entre servicios

En un monolito, "quién está llamando a esta función" lo responde la pila de llamadas. En una malla de microservicios, cada llamada cruza un límite de red, y ese límite de red es exactamente el lugar donde un atacante — o un servicio vecino mal configurado — puede aparecer haciéndose pasar por otra parte. Cuando tienes decenas o cientos de servicios hablando por HTTP o gRPC, "la petición vino de dentro de nuestra VPC" deja de ser un límite de seguridad. El modelo zero-trust trata cada salto, interno o externo, como no confiable hasta que se demuestre lo contrario, y demostrar lo contrario es exactamente para lo que sirve la autenticación servicio a servicio.

Hay dos respuestas dominantes a "¿cómo sabe el Servicio B que quien lo llama realmente es el Servicio A?": TLS mutuo (mTLS) en la capa de transporte, y cuentas de servicio/tokens (JWT?, OAuth2 client-credentials) en la capa de aplicación. No son excluyentes — la mayoría de las plataformas maduras usan ambas, en capas — pero en una entrevista quieren ver que entiendes qué demuestra realmente cada una.

#mTLS: demostrar identidad en la capa de transporte

En TLS normal, solo el servidor presenta un certificado; el cliente lo verifica y confía en el servidor, pero el servidor no tiene ninguna prueba criptográfica de quién es el cliente. TLS mutuo invierte esto: ambos lados presentan certificados X.509 durante el handshake, y ambos verifican el certificado del otro contra una autoridad certificadora (CA) de confianza antes de que se mueva un solo byte de datos de aplicación.

En la práctica casi nadie implementa esto a mano por servicio. Un sidecar de malla de servicios (Envoy, en arquitecturas estilo Istio/Linkerd) intercepta el tráfico entrante y saliente, termina el TLS, y maneja de forma transparente la emisión y rotación de certificados — tu código de aplicación simplemente hace una llamada HTTP normal a localhost, y el sidecar la envuelve en mTLS antes de que salga del pod. Los certificados normalmente codifican una identidad de carga de trabajo (un SPIFFE ID como spiffe://cluster.local/ns/payments/sa/checkout) en lugar de una identidad humana, tienen vida corta (minutos a horas), y se rotan automáticamente mediante algo como SPIRE o la propia CA de la malla — nadie quiere rotar manualmente 400 certificados de servicio.

#Cuentas de servicio y tokens: demostrar identidad en la capa de aplicación

La alternativa (o el complemento) es una credencial portadora que el llamante adjunta a la propia petición — lo más común, un JWT firmado obtenido mediante el flujo OAuth2 de client-credentials, o un token de cuenta de servicio de un proveedor cloud (un rol IAM de AWS, una cuenta de servicio de GCP, un token de ServiceAccount de Kubernetes?). El servicio llamante se autentica una vez contra un proveedor de identidad o emisor de tokens, recibe un token de vida corta, y lo presenta como cabecera Authorization: Bearer ... en cada llamada. El servicio receptor valida la firma y los claims del token (emisor, audiencia, expiración, scopes) sin necesitar una ida y vuelta en vivo al emisor, porque los JWT son autocontenidos y verificables sin conexión contra la clave pública del emisor.

#El tradeoff real

mTLS autentica la conexión — te dice qué carga de trabajo abrió esta conexión TCP, y lo hace para cada paquete, de forma transparente, sin cambios en el código de aplicación. Es excelente para defensa en profundidad y para cifrar el tráfico este-oeste, pero no dice nada sobre por qué se hace la llamada o en nombre de quién, y revocar una identidad comprometida significa revocar un certificado (que algunas CA hacen lento vía CRL, aunque los certificados de vida corta evitan esto simplemente no renovándolos).

Los tokens autentican la petición, y pueden llevar claims ricos — scopes, IDs de tenant, la identidad del usuario final original si el token es delegado/on-behalf-of — de modo que el servicio receptor puede tomar decisiones de autorización de grano fino ("este token tiene orders:read pero no orders:write"). Pero los tokens requieren integración a nivel de aplicación (middleware que los valide), y un token de larga duración filtrado es un riesgo real si la expiración y el alcance no están bien controlados.

#El handshake, con un sidecar en medio

Nota que el Servicio A y el Servicio B nunca ven TLS en absoluto — hablan HTTP plano con su propio sidecar por la interfaz de loopback, y los sidecars manejan el handshake criptográfico, la verificación de certificados y el cifrado. Esto es exactamente lo que permite a los equipos de plataforma desplegar mTLS en toda una flota sin tocar código de aplicación.

#Eligiendo entre ambos (o los dos a la vez)

Para una respuesta de entrevista, el cierre más sólido es: usa mTLS como base para toda conexión este-oeste dentro de la malla (es barato una vez que el sidecar está en su sitio, y elimina la suplantación a nivel de red), y añade JWT encima allí donde un servicio necesite tomar una decisión de autorización que dependa de algo más que "qué carga de trabajo es esta" — por ejemplo, propagar la identidad del usuario final original a través de cinco saltos de una cadena de llamadas.