I recently worked with a financial services client who required Mutual Transport Layer Service (mTLS) communication across Google Kubernetes Engine (GKE) clusters using separated Istio Meshes. We deployed client-side services in one GKE cluster and the application-side services in the second GKE cluster. Establishing mTLS within one mesh-even across multiple GKE clusters-is easy, but I encountered challenges in configuring mTLS between two meshes. After some troubleshooting and testing, I found the solution. This blog post will detail how I solved this challenge for our client.
Why mTLS
In most network communication, a server-side certificate from a trusted Certificate Authority (CA) is sufficient for session verification. The server-side certificate provides assurances to clients that the services it provides are legitimate. For example, when someone connects to www.google.com, the certificate assures the web browser that they are actually connecting to www.google.com and not a nefarious site looking to capture personal information. TLS and HTTPS are examples of traffic using server-side certificates. In these situations, the server does not require the client to be authenticated and verified.
Client-side authentication could be critical in sensitive communication scenarios, such as financial services, critical infrastructures, and defense. Other examples in which client- and server-side authentication is critical include closed communication paths, such as IoT, microservices, and Content Delivery Networks. Enter mTLS, where the client has a certificate from a CA providing assurances to the application side that the client is legitimate. Since both sides of the session are authenticated, traffic is more secure.