This tutorial shows you how to build a private multicluster service mesh solution, with Istio 1.5 and Service Mesh Hub for mesh Federation. This is achieved by using an Internal Load Balancer (ILB) to connect Istio workloads running in multi-region Private Google Kubernetes Engine (GKE) clusters.
Istio 1.5 was released on March 5th and with this major release, comes several important changes, however, support for Hashicorp Vault as External CA is still in progress. For this reason, I started to investigate what other options there are for managing the common root CA in a secure way. I then came across solo.io’s open-source project, Service Mesh Hub. Service mesh hub is a solution that can help you to unify the root identity between multiple service mesh installations. This means that any intermediates are signed by the same Root CA and end-to-end mTLS between clusters and services can be established correctly.
How it Works
In this tutorial:
we will build the following architecture:
There are several reasons to isolate your Google Kubernetes Engine (GKE) clusters from internet access, the primary one being security. In a private cluster, nodes only have RFC 1918 private addresses and communicate with the master’s private endpoint via private networking.” This prevents any access authorized or no from the outside internet. “
The TCP/UDP Internal Load Balancer has a less well-known beta feature, called Global Access. This feature allows clients from any region in your VPC network to access the internal TCP/UDP load balancer. Without global access, traffic originating from clients in your VPC network must remain in the same region as the load balancer. Global access is enabled, in your private Kubernetes clusters, on a per-Service basis by using the following annotation:
In the example implementation, we will annotate the ingressGateway Kubernetes Service directly to provision a GCP ILB with global access. After Global access has been applied we now have network connectivity in place between our private clusters running in different regions.
Success! Notice we have the service A (sleep.foo.cluster-1) that needs to talk to service B (httpbin.bar.cluster-2) in another mesh. If a service in one mesh requires a service from another, you must federate identity and trust between the two meshes. To do this you must exchange the trust bundle between the meshes.
Service mesh hub allows you to group together multiple meshes into an object called a VirtualMesh. Creating this resource will instruct the Service Mesh to establish a shared root identity across the clusters in the Virtual Mesh as well as federate the services.
Understanding the shared root process
With the creation of the VirtualMesh resource:
- Service Mesh Hub will kick off the process to unify the identity with a shared root.
- Service Mesh Hub will use a Certificate Signing Request (CSR) agent on each of the different clusters to create a new key/cert pair that will form an intermediate CA. Each cluster’s intermediate CA will be present and used by the mesh on that cluster.
- It will then create a Certificate Signing Request, represented by the VirtualMeshCertificateSigningRequest CR.
- Service Mesh Hub will then sign the certificate with the Root CA specified in the VirtualMesh.
- Once this process has completed, we need to bounce the
istiodcontrol plane. This is because the Istio control plane picks up the CA for Citadel and does not rotate it often enough. This is going to be improved in future versions of Istio.
Once trust has been established, Service Mesh Hub will start federating services, automatically generating service entries for you! so that they are accessible across clusters.
For this tutorial, the enforceAccessControl flag is disabled and this will be the subject for one of my next articles. Where we will see how Istio can provide security features for a strong identity, powerful policy, and authentication, authorization, and audit (AAA) tools to protect your services and data.
In this tutorial, I have demonstrated the ease with which you can implement a service mesh solution with intra-mesh communication. Service to service communication can happen internally via secure mTLS traffic communication, without leaving the Google Cloud’s Global Network.
The step by step instructions, for this tutorial, can be found here:
- Implementation code — https://github.com/palimarium/multicluster-istio-smh-private-gke
- GCP — Private GKE Clusters — https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters
- GCP — TCP/UDP Internal Load Balancer — https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
- Istio-Configure the example service — https://istio.io/docs/setup/install/multicluster/gateways/#configure-the-example-services
- Service Mesh Hub — Concepts — https://docs.solo.io/service-mesh-hub/latest/concepts/