solo.io Istio Service Mesh, 16 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Part Two - Multi Cluster Istio Deep Dive with Service Mesh Hub

Description

Service Mesh Hub is a Kubernetes-native management plane that enables configuration and operational management of multiple heterogeneous service meshes across multiple clusters through a unified API.

Service Mesh Hub simplifies discovery, trust domain unification, access policy, and L7 traffic routing among other things.

In this demo, we look at unification of identity and trust domain across multiple meshes.

A

Thanks again for stopping by our youtube channel, this is Christian posta from soulard nao. This is a continuation of a series of demos where we dive into service mesh hub and its capabilities. In the previous demo, we saw its ability to discover clusters and meshes and workload items that are running inside of those particular meshes, and specifically, we started with two steel clusters now in this demo.

A

What we're gonna do is we're going to take a look at federating, the root identities across the two different meshes, because they start it off to spare it we're gonna, bring them together so that we can route traffic across them in the next video, we'll look at using a unified API. On top of this new virtual mesh and control things like access policies and network routing and so forth. So let's get started just to remind you.

A

We have sto installed in cluster 1 and we have sto installed in cluster 2 2, separate installations of Sto and our service mesh hub, which is our management plane.

A

So we have our clusters and we've discovered our meshes as well. So now the two different meshes have different route trust domains here. So, for example, if we look at reviews calling in to the rating service, let's come back up here: reviews calling in to the ratings service.

A

We can see the certificate that gets presented. We can even see the full chain here right, so we have here's the route we see GGY as the last part of it.

A

If we take a look at the auto-generated secret created by sto when it started up, we can see that that, indeed, is the root of its that's, to see it as the CA that it's using and that's why we see that when we see the mutual TLS between sto services in cluster one now, if we do the same thing on cluster two first, we should notice that this root is different.

A

So, let's back up here, take a look at the chain.

A

The root that we see here is different than the previous one, but this case EQ should match the root CA that that sto auto-generated when it started up which we did okay, see cute. So that's we see that these are two different service messages with two different trust domains.

A

Now, what we're going to do using service mesh hub is unify them using a a contract called the virtual mesh we're going to group them into a single logical mesh, and we can see that here, the virtual net, using the virtual mesh CRD, we're going to say, generate a route that will be the root of both of the meshes. If we already have a CA a root CA, we could specify it here in this case, will generate one we're going to federate the meshes and make them permissive to start off with. For this demo.

A

Permissive just means that the service discovery between the two services will be global. So you can see all the services in clubs are two and in cluster one we're going to start off by not enabling access control. So everything can talk to everything, we'll see that in the next demo- and these are the meshes that we are going to group.

A

So let's apply this virtual mesh and you can see we're applying it to cluster 1, which is where the management plane here lives the service mesh hub. So that says it was created. Now if we go and get this resource, we should see the same thing that we expected, but then in the status field- and this is actually important detail too. All of the service Mashhad resources, there's a status field- gives information about the the state machine behind it right now, except the acceptable transitions and their their states.

A

We can see everything that was accepted here. So that's good. Now, we've created this virtual mesh abstraction. Let's take a look at the secrets that were created right, so we asked a service mesh hub to automatically create this route CA, and we can see that here and let's take a look at that particular route CA and let's take a look at the certificate itself, so we can see here, let's actually copy this. It ends in ns I with the equal sign. That's just those copy it here.

A

So we have it yep that so now, when we created this virtual mesh, what this instructed the service must have to do is ask each cluster each service mesh to generate its own keys and an certificate and certificate signing request that will act as intermediate and form a chain between what's running in the particular clusters and ultimately, this root CA that we created. So we can see if we ask for the the virtual mesh certificate signing request.

A

We can see that on cluster 2, it also exists on cluster 1 and, let's actually take a look at this see a whole bunch of stuff. Here here is the the the host name and the and the org for which we want this certificate signed. The csr data here is base64-encoded, but we can see in the status field. Like I mentioned the response, so we have the CA signed and we have the route that was used in this particular chain. Again, it's base64 we'll take a look at it in a second now.

A

What this means is: we've created a new key and certificate pair on each of the meshes without transmitting any keys or certificates across the network other than the certificate signing request, and we can see that in cluster 1 we created a see a search for Sto and in cluster 2. We did the same thing now. If we look at the root cert from our from the see a search that was created, we can see NS I with the equal sign and that matches what we expected from our root search from service mesh hub.

A

So let's bounce the ischial pods, the the SPO control plane, and at the moment we we need to do that because it doesn't pick it up automatically. Let's do that on cluster 1 and cluster 2. That is something that we are working on at Isola will contribute that to to SDA. Let's get down that working and then another thing that we'll notice, if we come over here, real quick, is that the I've also restarted the workload so that they pick up the new certificate chain. It eventually does happen, but it it takes a little bit.

A

So we just speed it up by by bouncing them and that's fine, ok! So now, let's take a look at the pods okay, so the pods that are running from the from the book info. We see that they're all running they're all running nicely.

A

Let's now check the certs again so in cluster 1 we see reviews calling ratings, we're going to look at that that certificate chain- and we see it here- here's the root here and we should see.

A

Where is the root? The root is right here and we can see NSI does that match? Yes, it does so now. Our trust domain on the first cluster is anchored on the root CA that we generated for service mission with service Mashhad. Let's take a look at cluster to do the same thing come up here and look at the root certificate in the chain. We see NSI and again that matches so now both clusters are federated in terms of their trust amis.

A

So, in the first video we saw how to discover these clusters. In this video we saw how to how to unify their their their trust and, in the next two videos we'll see access policy treated at the virtual mesh layer and traffic routing at the virtual mesh layer. So stay tuned watch the next videos.