Cómo inspeccionar tráfico mTLS en pods de Kubernetes con cURL

Por qué mTLS protege los microservicios en Kubernetes

En los entornos modernos de infraestructura, garantizar que un contenedor se comunique únicamente con pares autorizados es una necesidad operativa fundamental. Aquí es donde entra en juego el mTLS, o Transport Layer Security mutuo, un protocolo que exige tanto al cliente como al servidor presentar certificados digitales válidos antes de cualquier intercambio de datos. En la práctica, esto significa que el cifrado por sí solo no basta; cada microservicio debe probar su identidad criptográfica en la red del clúster, evitando escuchas indebidas o manipulación de mensajes entre aplicaciones vecinas.

Al adoptar mallas de servicios o Service Mesh como Istio o Linkerd, esta protección ocurre de forma automatizada mediante proxies laterales inyectados junto a nuestra aplicación. Sin embargo, cuando ocurre un error de apretón de manos (handshake) —es decir, cuando la negociación inicial de seguridad falla y la conexión es rechazada—, descubrir la causa exacta se convierte en un rompecabezas complejo. A menudo, el tráfico se bloquea silenciosamente, generando registros crípticos que no apuntan a ningún culpable evidente.

El desafío de depurar fallas de TLS en entornos aislados

La depuración de redes en clústeres de Kubernetes suele ser estresante porque los pods se ejecutan en espacios de nombres aislados, frecuentemente sin herramientas de diagnóstico tradicionales instaladas en las imágenes de producción. Cuando el tráfico está enmascarado por cifrado mutuo, inspeccionar paquetes con herramientas de captura de red como tcpdump solo muestra bloques de datos cifrados ilegibles, sin revelar por qué el servidor rechazó el certificado.

Para empeorar las cosas, antes de revisar la red, problemas subyacentes de infraestructura como los cuellos de botella descritos en auditorías de límites de contenedores pueden tumbar el proxy y simular una falla de conexión inexistente. Por ello, aislar el problema exige imitar la llamada exacta que realiza el microservicio, inyectando manualmente los mismos certificados que distribuye el Service Mesh mediante un cliente HTTP versátil como cURL.

Cómo extraer certificados y claves desde un pod en Kubernetes

Antes de ejecutar comandos cURL, necesitamos recopilar los secretos criptográficos que el clúster generó e inyectó en el pod de origen. El mTLS depende de tres elementos principales: el certificado público de la autoridad certificadora (CA), el certificado del cliente y la clave privada correspondiente que demuestra la propiedad.

Normalmente, estos archivos se almacenan en volúmenes montados dentro del contenedor, a menudo en el directorio /etc/certs o en secretos de Kubernetes montados mediante volumeMounts. Para inspeccionar estos archivos sin alterar producción, podemos abrir una terminal interactiva en un pod efímero de diagnóstico o copiar los archivos directamente usando la utilidad de copia remota de Kubernetes:

kubectl cp mi-namespace/mi-pod-abc:/etc/certs/tls.crt ./tls.crt && kubectl cp mi-namespace/mi-pod-abc:/etc/certs/tls.key ./tls.key

Con los archivos guardados localmente, podemos revisar fechas de expiración y nombres alternativos de sujeto (SANs) usando OpenSSL para asegurar que el certificado sigue vigente y pertenece al servicio que intentamos depurar.

Ejecutando cURL con mTLS para simular llamadas entre pods

Con los archivos de certificados listos, el siguiente paso es armar el comando cURL apuntando a la IP interna del pod de destino o al nombre de servicio en el DNS interno del clúster. Como el servidor exige autenticación mutua, debemos indicar explícitamente el certificado del cliente (--cert), la clave privada (--key) y la CA que valida el certificado del servidor (--cacert).

Para ejecutar esta prueba en la práctica, siga la siguiente secuencia desde el interior de un pod de apoyo con cURL instalado en el mismo clúster:

1. Copie los archivos de certificado y clave privada al directorio de trabajo actual del pod de diagnóstico.
2. Ejecute el comando cURL pasando los parámetros de mTLS apuntando al puerto seguro del microservicio objetivo.
3. Analice el código de estado HTTP devuelto y el registro detallado del apretón de manos generado por la bandera de verbosidad.

El comando práctico para esta prueba adopta la siguiente estructura detallada:

curl -iv --cert /tmp/tls.crt --key /tmp/tls.key --cacert /tmp/ca.crt https://servicio-destino.namespace.svc.cluster.local:8443/api/v1/status

Las banderas -i y -v son cruciales aquí: muestran las cabeceras de respuesta y todo el seguimiento detallado del establecimiento de la conexión TLS, permitiendo identificar con precisión en qué etapa falló la negociación.

Interpretando errores comunes de handshake y resolviendo problemas

Cuando cURL devuelve un error de conexión, la salida en la terminal suele revelar la raíz del problema. Si el error indica SSL certificate problem: self signed certificate in certificate chain, significa que el servidor presentó un certificado firmado por una CA desconocida para el cliente; la solución es verificar que el archivo en --cacert coincida exactamente con la CA raíz emisora.

Otro error clásico ocurre cuando el servidor rechaza al cliente con un código de alerta de handshake, indicando un certificado de cliente expirado o un dominio que no coincide con las políticas de seguridad del Service Mesh. Validar estos detalles elimina obstáculos invisibles y devuelve previsibilidad operativa a la arquitectura.

Consideraciones finales sobre diagnóstico de redes en mallas de servicios

Inspeccionar tráfico mTLS en pods de Kubernetes utilizando cURL es una habilidad indispensable para ingenieros que manejan arquitecturas distribuidas complejas. Aunque las mallas de servicios automatizan gran parte del cifrado, comprender los mecanismos subyacentes de certificados y saber forjar peticiones manuales acelera drásticamente la resolución de incidentes en producción. Dominar esta técnica transforma fallas oscuras de red en diagnósticos rápidos y precisos.