Autenticación entre servicios y TLS mutuo

En una malla de servicios (Service Mesh como Istio o Linkerd), cada pod cuenta con un contenedor proxy sidecar (Envoy) que intercepta todo el tráfico de entrada y salida. El plano de control de la malla asigna a cada pod un certificado X.509 de vida muy corta (ej: 24 horas) con un identificador unívoco conforme al estándar SPIFFE (Secure Production Identity Framework for Everyone, ej: spiffe://cluster.local/ns/pagos/sa/svc-pagos). Los proxies negocian mTLS de forma transparente, cifrando el canal y verificando la identidad mutua antes de transmitir datos.

El modo PERMISSIVE en una malla permite conexiones cifradas pero acepta también tráfico en texto claro sin autenticar, siendo una etapa de transición pero un riesgo en producción.

Abre el laboratorio y lee politicas-peer-auth.txt. Identifica qué namespace opera actualmente en modo PERMISSIVE dejando expuesto el tráfico.

En namespaces con datos transaccionales o de pagos, la directiva debe forzar mTLS obligatorio sin excepciones.

Revisa la tabla técnica y consulta el modo de autenticación configurado para ns-pagos-seguros y ns-core-comercio.

La emisión de certificados efímeros de 24 horas administrados por la autoridad de certificación de la malla (Citadel) elimina la pesadilla de certificados vencidos en comunicaciones internas.