solo.io Gloo Mesh - Service Mesh - Deep Dive, 28 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Multi-cluster Service Mesh Identity and Access Control

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hi welcome everyone to this uh new video on this series about uh service mesh hub. I am duni geno director of field engineering at solo, and you can find some information about me and also my youtube channel, where you can find many different recording.

A

What we do in this series is that we go through these different challenges when you want to manage multiple service mesh deployments, and we already went through some of them. We already went through the federated trust and identity.

A

We went through multi traffic, multi-cluster traffic and in this video we'll focus on how you manage access control globally, we covered the federated identity in the first video, but I thought we didn't go deep enough to really understand what we need to understand for this uh global access control so we'll go through it again, but a little bit deeper at that time.

A

So the way istio identity works is that the sidecar proxy that runs with the workload is asking for a certificate to be signed by histo and then is using this certificate to prove its identity when it communicates with other workloads. So it's it's a really important concept about. You know how this service to service authentication work, and even if you enable everything when you install this, to um keep in mind that the mutual tls authentication is not automatically enforced, so you have to really enforce it uh by creating creating a peer authentication object.

A

But when this uh peer detection object is created and meteor tls is in place, um the way it works is that the client-side invoice start the mutual tls and check with the server side envoy and that's where these certificates are used to prove the identity of the two component of the client on the server and um for that they need like a unique id and unique identifier, and spiffy is used for that.

A

So spiffy is the secure production identity framework for everyone, so it's a set of open source standards and in spiffy standard you have this notion of a spiffy id and the spiffy id would look like this uri here, which is like uh composed of the truss domain and the workload identifier.

A

So if we look at the way the spf id is used in sto, you get something like the trust domain, slash ns, then the namespace slash sa and then the service account and the default trust domain is cluster.local.

A

When you deploy istio and that's fine, if you have one cluster, but when you start to have a multi-cluster deployment, then that means that there is no way to, for example, if you have this pods uh that is started with the sales account pod sa in the default namespace, the spf id will be like that, and there is, there would be no way to differentiate that service from the same one running on another cluster with the same service account the same namespace and perhaps even there are different workloads.

A

So if you and that's why I wanted to cover this, this part in more details in this access control, video, because obviously it has a big impact on access control, because the access control uh in istio is based on the service accounts. So if you don't change this domain and you just keep one trust domain, that is the same for all the clusters, then there is no way you can create access control rules that will take into consideration the unique identity of of each service.

A

And what we are going to do here is that to do a demo of this global access control uh with uh two clusters that are deployed through this, uh you know replicated control, plane model which is the most popular one, where basically, you have an istio control pane on each side and when the services, when you want to have service to service communication across the cluster, then it goes through this istio ingress gateway and obviously, if you have empty lace, enabled you want that guy to have a unique identity that he can prove to this other guy here, which has its own identity as well.

A

But here you don't want to have this cluster.local thing, so that's for the identity part. But then, obviously we speak about authorization here in this video and I won't go through the details.

A

But you have this notion of authorization policies in um in istio that allows you to define which workload can talk to which workload and it's not always straightforward to to use them when, when you need to have multiple services, communicating with the same service or things like that, because you need to add some more uh information in the same object- and that's that's not always like easy to do, but we we will go through that in the in the next slide as well.

A

So the service mesh up project uh is really allowing you to simplify everything here so that you can do things like that. You can have uh your communication coming from one site and you know going through the different micro services.

A

You can manage the traffic uh easily. You can even simplify the way one service on one side can talk to a service on another site. We went through that in the in the second video, so we won't cover that in details. Now you also want to have these shared routes so that one service here can validate the identity of another service that is under the site.

A

So you can do a lot of things with serious measure, but basically it really simplifies your life when you have this multi-cluster deployment and it does that by leveraging two different services, one, that's called the discovery service and the other one. That's called the networking service, so the discovery service will discover automatically all the workloads. So here, for example, that cluster is not aware of what's running in this cluster.

A

So if you would like to this cluster to be able to communicate with the review service here to this product, page chlorinated to the review on the other side, then you need to manually create a service entry and to build all the logic to alloy it, to communicate with it and like we've, seen in the previous video with service mesh hub, everything is made easy and automated, so that, because we discovered all the workloads of all the clusters, then we can automatically create the service entries on the cluster so that it knows about all the other workloads running globally and then the mesh networking component is enforcing the rules that you define in a simple language in servicemeasure.

A

So you create traffic policy like we've seen in the previous video, where you can say, I want to send this percentage of requests to the local review service and this percentage to the remote review service. But you can also easily create access policies that will be applied globally and that's what we will focus on in this in this video. So, let's jump into the demo here.

A

What you see is that we have like uh um three uh clusters deployed with kind and we have like kind one where we have the size mesh up running and then we have kind two and kind three where we have easter running and that has been deployed and the virtual mesh has been uh created.

A

And if I move forward, then what we did is that when, when we created this virtual mesh, it has created this new root set and it has used a third agent deployed by virtual mesh by service mesh herb on the two clusters here and it has signed these uh certificates created on each cluster with this common root cells, and these new sets are basically intermediate certain the chain so that you would have like the workload set signed um with this chain so that you have like the chain will be the the workload search.

A

Then the intermediate cert, which is different on each cluster and then the shared route, so that allows one one sidecar proxy running here to validate the identity of another one running in the other side.

A

So what we are going to to check first is what is the current state and the current state is that we didn't enable airbag. So I should be able now to access any any workload. I should. I should have everything uh just working now, so I'm going to jump in the in the cluster here and I was deploying it. I don't know if it's ready. Yeah, it is so we see here.

A

I have access to the product page service that has access to the review service that acts access to the rating service, because everything is is working well now. So the first thing I'm going to do here is that I'm going to enforce airbag, so I created the virtual mesh before and here I'll just modify it so that I have like airbag enabled globally. So I just going to do that here, just like creating this new rule and very quickly, I should be able to see here that I will get like a denied.

A

So let me check here yeah, you start to have some services that cannot talk to the other services you see, and even the istio ingress gateway itself cannot even talk to the product page anymore. So I have denied everything. So the goal here will be to allow the communication, but only the communication we want.

A

So if I go there- and I see when I enable airbag- what it did in fact is that it created these uh autoresolution policies, so it created one with the spec that is empty, which means that and in this your name system namespace, which means that nothing is allowed. Basically, that's that's what it means, and then it's created this authorization policy just here on cluster 2 and created the same one here on oops, where I am on cluster three to just allow access to the eco ingress gateway itself.

A

But then this regression gateway cannot talk to the product page. So we are in this stage we can access the student gateway, but we cannot do anything apart from that. So what we are going to do now is that we are going to create what we call an access policy and the access policy will tell. I want the istio ingress gateway service account, so the steering wheel gateway on kind 2 to be able to access any service with the label service product page in the default namespace.

A

So I'm going to do that here.

A

And if I refresh very quickly, I should see that I can access now the product page, but still the product page, cannot talk to the other services.

A

So what it did when I created this access policy, it translated it in an authorization policy, and you see the authorization policy contains this kind 2, which is the the the trust domain that we have on this cluster and kind three, the trust domain that we have in the user cluster we deployed it with separated trust domain and and, as you can see like um everything is done in a simple way and you define all these policies in the single cluster, which is the cluster where service mesh hub is running.

A

Even if you have 10 different clusters with service mesh, then you just define all your rules in one location and they are enforced in the cluster that you you target and now, if I want to allow uh the product service to talk to the details and the reviews, then that will be very similar like you can see.

A

That's the service account of my product page, and these are the services I want to allow. So I just going to create this hole and very quickly again, I should be able to access them, but you see, the rating service is not available, because I didn't allow the review service to talk to the rating service, but again just to summarize what we've just done before.

A

We upload that communication here and now, we've allowed this communication there so that the product page can talk to details and review and the way it worked is that we created a single access policy, but it created the authorization policy for both because that's one pair target- and here we we just use that source. So now. The next step is to upload the details, the review service, to talk to the rating service, and we can see that here we just have the review service account on kind 2. That can talk to the rating service here.

A

So if I apply that word and I refresh again.

A

Then I should be able to see them very quickly. Yeah, I can see them so that shows you how to do it very simply in the local side, but the value really comes when you start to do that globally. So you remember last time we spoke about this multi-cluster traffic and how you I can some of the requests from public page going to reviews here and some going to um the reviews on the second site.

A

So we are going to do the same here. So let me go back to the slide quickly. That's the current state. I can access the product page and the product page can access the rating and the access policy. The last one I created just created this authorization policy here and now what we want is to be able to access the other one here.

A

So I won't go through the details about how to do that, because that's what we covered in the second video, but basically we create this traffic policy to say that I want to send 75 percent of my request to my other cluster and still and version 3 of this one, and then I want still to send some of the requests to version one and two locally.

A

So I'm going to apply that's full and that's again I encourage you to watch the second video if you want to understand that because it does a lot of this of thing behind the scene to make it easy in in real life. If you have just the twist to you- and you have to do that by yourself- you have to create five or six different objects just to express that.

A

So if I go back here, I should start to see some with the red stars, but no because, as you can see, I am not allowed to do that because here the review service needs to talk to the rating service, but what we have allowed so far.

A

If I go back here that we have upload the review service, no, it's that one, the review service of kind 2, so the service icon that represents this one, which is with this unique id that start by k2, can talk to any service in the default namespace with these labels.

A

So that means that the review service that is here can talk to this guy, and it could talk to this guy because we didn't say that we didn't we wanted on it target one cluster, it just like any rating service on the default namespace, but this one we didn't have any rule for it, because this one is not using the service account kind to slash whatever it's using kind, three slash whatever so to allow that we need to create an additional access policy or we need basically to modify the access policy we created before, but instead of saying that this policy is for the source, which is only reviews booking reviews.

A

uh Second of kin two. We want also it to be working for the one running on kind three, so I can now apply this rule and if everything goes well then I should be able to refresh- and I see I can now access that, so it's really showing the power of having this global access control.

A

Where in one location, you can use simple objects that are called access policies to express globally, which services can talk to which services? And you see here- we are like going to the product page, which is like on the first side. If we would try to go on the second side here, I still have an access denied, because I didn't do anything there. I didn't allow the ingress gateway of this site to talk to the ingress gateway the product page at all.

A

So it really just show you, you know you can easily determine what, where you expose your services to the outside world and then what kind of communication you roll across these different services.

A

So that's that's what we cover now. uh We still have like uh other videos coming uh one where we speak about uh different service mesh technology. So basically we'll show you that this kind of access control that you apply with um ecu you could use service mesh up to apply them also with other technology like osm. I think we will use osm for that one. We still have also to go through. You know how to manage failover and we will even add probably another topic about. You know how you secure the edge.

A

So I'm going to to work on that um and and just to summarize about our portfolio- um that's how it looks like we focused here on the service mesh up here. We, as I said uh I have a pro. We will probably have a topic on. You know how you can secure the edge. You can do that with the steering wheel gateway, but it's quickly quite limited. So we will show you how you can do that with a proper api gateway like glue.

A

Obviously, you can use glue without a service mesh if you want to secure the edge.

A

You have also like a developer portal that is available in both cases, if you use istio or if you use glue you're able to expose your api with the developer portal, let your user get the access key. We discovered the api with. You know, open api specs and we create all the routing behind the scenes.

A

So it really makes your life a lot easier when you want to expose apis to the outside world, and we we are also very active in this- was me web assembly topic where, uh in the in the near future, you'll be able to easily build your own android filters and distribute them across your environment, which can be again distributed to this envoy sidecar proxy running on istio, but also applying them to glue, because glue is also based on on android.

A

So I hope you enjoyed the video and, uh and hopefully you'll uh you'll, have a look at the next ones as well. Thank you very much.