Malla de servicio y mTLS

Con TLS mutuo (mTLS) las dos puntas de una conexión presentan un certificado: la conexión va cifrada y cada carga sabe con qué identidad (por ejemplo, la de su cuenta de servicio) está hablando. Eso es autenticación del par y confidencialidad en el tránsito.

No es autorización. Que una carga sea una identidad válida de la malla no dice que pueda llamar a cualquier otra. La decisión de quién llama a quién se escribe en reglas de autorización, que en una malla actúan sobre la identidad, el método y la ruta, es decir, en la capa de aplicación, más fino que una política de red, que decide por dirección y puerto.

Las mallas suelen ofrecer un modo permisivo: acepta conexiones con mTLS y también en claro, para facilitar la migración mientras no todas las cargas tienen proxy. Es un modo transitorio. Se queda, se olvida y se convierte en la razón por la que el cifrado que se creía obligatorio no lo es. El modo estricto acepta solo conexiones con mTLS.

Consulta la tabla modo_de_la_malla.

Una regla de autorización dice quién (qué identidad) puede llamar a qué destino y con qué método y ruta. La regla útil es corta: «el servicio de pedidos puede hacer GET a las recetas». La que preocupa es la que admite cualquier identidad de la malla: cualquier carga comprometida dentro de ella, con su certificado válido, la cumple.

Consulta la tabla autorizaciones.

Una carga sin proxy lateral (fuera de la malla) no tiene certificado de malla y habla en claro. Si el destino está en modo estricto, la conexión se rechaza; si está en modo permisivo, se acepta. Por eso las cargas fuera de la malla son el motivo habitual para dejar en permisivo un espacio y, al revés, un punto ciego: la malla no puede decir nada de lo que no la usa.

La tabla de conexiones observadas dice si cada una iba cifrada con mTLS y qué hizo la malla con ella. Contar las que no iban cifradas y se aceptaron es el número que mide cuánto de lo que se creía cifrado no lo estaba.

Consulta la tabla conexiones.