mTLS, qué protege y qué no

En TLS normal solo el servidor demuestra quién es. En mTLS (mutual TLS) también lo hace el cliente con su propio certificado, de modo que cada extremo conoce la identidad del otro y el tráfico viaja cifrado. En una malla, los proxies hacen esto de forma transparente para la aplicación.

Eso responde a dos preguntas: «¿quién llama?» y «¿alguien puede leer o alterar el tráfico en tránsito?». No responde a una tercera, «¿debería poder hacer esta petición?», que pertenece a la autorización.

Istio ofrece, entre otros, el modo PERMISSIVE (acepta mTLS o texto plano) y el modo STRICT (solo mTLS). Si no se declara nada, se hereda del padre y, en último término, se trata como permisivo. Un modo permisivo es útil para migrar, pero deja la puerta abierta a cualquier cliente que hable en texto plano: la política «parece» de mTLS, y no lo exige.

Abre malla/peerauth.yaml.

El registro del proxy anota por cada conexión si llegó por mTLS o en texto plano. En un namespace sin modo estricto, las conexiones en texto plano son legítimas para el proxy, pero ya no llevan identidad: no se sabe quién es el origen más que por su nombre de pod.

Cuenta cuántas veces se aceptó la base de datos una conexión sin cifrar.

El proxy del servicio de exportación registra, además de la identidad, si una política de autorización decidió algo. La anotación sin-politica significa que ninguna lo evaluó: cualquier identidad válida de la malla puede pedir cualquier ruta. Es la situación de un mTLS bien puesto sobre un servicio sin autorización.

Busca en el registro una petición a una ruta administrativa que se atendió con éxito.

Pasar un namespace de permisivo a estricto rompe a todo cliente que hable en texto plano, incluidos los que están fuera de la malla o los trabajos que se saltan el proxy. Se hace con el registro en la mano: primero se identifica a los orígenes en texto plano, se les da proxy o se acuerda su retirada, y solo después se cambia el modo.