 Okay, we are going to get started. Hello everyone, thank you very much for taking time out of your day for joining us for today's CNCF webinar, Security in the World of Service Meshes. I'm Jerry Fallon and I will be moderating today's webinar. We would like to welcome our presenter today, John A. Joyce, Principal Engineer at Cisco Systems. Just a few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There's a Q&A box at the bottom of your screen, so please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct, so please do not add anything to the chat or questions that are in violation of the Code of Conduct. Please be respectful of your fellow participants and presenters. And please also note that the recording insights will be posted later today to the CNCF webinar page at cncf.io slash webinars. And with that, I will hand it over to John for today's presentation. Hi, everybody. I hope everybody's having a good day. As Jerry said, my name is John Joyce. I've been at Cisco for quite a while, many, many years. And about the last five or six or so I've been working predominantly in cloud related businesses. A few years on OpenStack, a few years on Istio. In the last couple of years, I've been spending a bit of time on network service mesh and some other related projects that we might cover a little bit today. So let's let that let me get started. Okay, here's the agenda. So the part a little bit of the agenda is going to be more educational. Talking about how mesh security lines up, what kind of things are happening in the mesh security world, what kind of features and functions are being used. But then we'll move on to some current implementations a little bit on some of the stuff that is happening and some of the things we are doing also within those communities to promote different choices and architectures. So the purpose is just the abstract. You've all seen this so I'm not really going to spend any time on it. It'll be in the slides if you want to look at it, but it's pretty straightforward. It's what got you here. So let's talk a little bit about what security and the service mesh means or what are the key things. So let's start with some definitions. So the first the most important thing is we need identity. So we need some way of deciding a thing person process module whatever you want to call it is who they are and a way to track and certify that that that that thing that element is what it is. So that's that's the first and most important thing that that kind of triggers all the rest of this talk. So once we have identity then we want to do something that's often called often in this environment or authentication. It's the verification of the identity we want to make sure that who we're talking to is who they say they are. So when we start talking about service meshes, there's a couple different forms of that authentication. There might there's probably even more than I left here but these are the two ones that I'm going to really cover a little bit in this talk. One is what we might call transport or peer authentication and it's sort of the immediate authenticating your immediate peer. So the actual flow or request maybe going through intermediaries and of course in a service measure typically going through proxies. So you usually have lots of intermediaries between the the ultimate beginning and the ultimate end of my flow or request. There's also something called origin or request off there's a couple different names for this you might see out there besides even the ones I list here. And this is actually trying to make sure that both the sender the the initial sender and the final receiver have some ability to authenticate each other, or at least authenticate one side of it. Then we talked a little bit about authorization, which is sort of now that we know an identity or assuming we know an identity. You might want to grant different privileges or access levels to that identity. So it's a little bit the next level of choice and it gives you a lot more granularity and control over how you might want to do things. So how do we want to express that identity? Well, there's two things definitions here certificates, which include a key and an identity and typically in this space we're dealing with x 509. And then that's it. We'll talk about this a little bit more. It's a spiffy document identity document. It's transport layer security is the key sort of protocol we'll be using when we're talking, especially when we're talking about peer or transport authentication. So we'll talk about TLS quite a bit and zero trust to hear that they're all over the place these days. I chose to put this definition here because I thought it was best there might be others. And it's used in marketing all over the place these days, but it's really trying to say, hey, you don't assume any peer is trusted, regardless of who, what kind of domain scope network, whatever, you know, whether it's in front of the firewall behind a firewall, in a VPN. The idea is that you don't trust anybody. And you want to make sure you go through authentication and even authorization steps with everybody you talk to. So, when we talk about service meshes, there's a couple TLS flavors that we should talk about. So I've kind of listed them here. TLS is sort of the gold standard. That's what most meshes service meshes seem to be trying to get to, but not all of them are there yet. Then there's also a server side TLS, which is where the basically the server presents a certificate that the client can authenticate but not the other way around. And then sometimes there's some of the meshes support even client TLS where the client presents a certificate and the server doesn't present its identity. So you only do TLS. The encryption is obviously good, but not both sides aren't authenticated from an identity perspective. So a couple of references here just the only real thing I want to say on this slide other than you would have it is that I'm going to talk a little bit about network service mesh. And for those people that are very familiar with what I like to call application service mesh, like Istio and Linkerd, network service mesh is different. It's not dealing much with layer seven at all. It's dealing more with layer three or four. We like to kid Ed Warnacky, who's one of the big promoters from Cisco of that technology that he just hijacked the name and he'll agree. So he kind of took advantage of the service mesh sort of PR and kind of used the name to, but it does represent some of the same mesh concepts of trying to interconnect things. He just does so more like a layer three and four constructs and a layer seven constructs, but I'll talk about that a little bit here later. So, well, how do we want to establish an identity. So when we're talking about service meshes, we'll talk about workloads, we'll talk about pods, you know, those kind of things. But we need to establish an identity and I borrowed this bullet list from one of the Istio decks. I'm not sure it's still there might be a little antiquated the current times but these are the types of identities that are used within service meshes to kind of key to a workload so that we can recognize them. I'll list them all here. I think many of these should be familiar with people. The one thing I do want to point out and we'll talk about this quite a bit later on is a spiffy and spiffy is a CNCF project. And it's a specification of how to represent identity and a little bit of how to do some all then spires and implementation of that, which is also CNCF projects spires one implementation of the spiffy specification. I'll talk about these a little bit below. But these are really starting to be some of the key cloud native capabilities to establish an identity and to be able to validate it that identity, although it sometimes relies on some of the above constructs like Kubernetes service account as we'll see later. So, well, one of the key things we need to do once we have that identity is while we need to get it into a certificate, we need a way to present that identity to appear so they can authenticate it. So, this flow here is a common flow that service mesh is used a common way that they handle generating a certificate with an identity so that it can be authenticated by a peer. So the private key is generated by the workload, but then the assigning request is sent to the control plane so that they can find that key and therefore it's authenticateable by a peer. And the control plane can self sign it the number of choices here the two I mentioned here is that you know self signed route certificate or maybe the signing is comes from an external source like vault. Then the control plane provides the proxy. That's certificate scope to the identity of the pods. In other words, the proxy can only use that certificate when connected within the pod of the associated service account control plane manages the rotation. Sometimes quite a few meshes support optionally or even perhaps it's the only option to do this less automatically and just mount them via files or whatever into the pods and proxies directly. So, let's talk a little bit about the authentication layers. So, this is an example of the two sort of layers that I talked about before, where, you know, we have a proxy workload a communicating to workload see it has to go through a bunch of intermediaries maybe maybe this middle piece here is just ingresses and egresses perhaps. But it's going to go through some intermediaries to get from the ultimate sender or from the original sender to the ultimate server receiver. So, what we want to do is want to make sure that at each hop along the way, we can do some transport often. And if we can do that via mtls that's best provides for encryption of the communication, whether it's tls or mtls but if it's mtls then not only does it provide the encryption but it also ensures that that each side has sure who they're talking to. And then, independent of these hops, there may be a need for the proxies or desire for the proxies to do some what I label here original where the proxy will actually be able to ensure that it's not at the initial sender and the initial receiver do some communication to make sure they are who they expect they are. Now, in this case I show the original all being done between the proxies but of course that can also be done directly by the workloads in some fashion outside of the scope of the service mesh itself. So, here give the sequence I borrowed the sequence from a site here that I list. It is just, I mean there's nothing special about this from the perspective service meshes but I wanted to make sure people who are not familiar with mtls understand sort of the sequence but you'll basically have a client with some client certificate of both who they are and keys and whatnot associated with its identity and server will have something similar. The client will request to protect the resources then there'll be a handshake back and forth so that they can present each other certificates. During that handshake each side will use some kind of method shown here it's a certificate authority some kind of method to ensure that the, the, the pier that it's talking to is who they expect they are. If those certificates are all to a common root then then it's all within the certificate itself is verifiable but there's other techniques to that are emerging to go beyond just a common root certification. But each side does that and then at the end they the server. The client is able to access the protective resource. So, let's talk a little bit about single sided tls versus mtls so. So, mutual I said mutual tls is a gold standard but it's not the only option that can be supported there's a couple reasons for this I list them here. I won't necessarily go through all the bullets here so you can read read ahead a little bit but I mean the main idea is that you don't you can't assume always that you have full authentication with both sides of a connection or lots of reasons why you may need to communicate with someone that you identify. But but at least knowing that then you have the capability to take different protections or controls or whatever to help protect both yourself and any other peers behind you within the same security networking domain whatever you want to say. And when you can't do mtls or you know some of the measures may not support it, then single sided tls is useful because it'll provide you the encryption. As I talked about before, there's both the server side which is very, very common in most of the service messages out there. The client side support is available in some cases but many measures don't support like a client side certification. And of course, many of the measures also support clear talks, but the expectation is the clear text is more for debugging or, you know, trialing or other reasons and wouldn't be production. So once the peer has authenticated, the next step is to decide it's authorized. So authorization will determine the, you know, what the descender and receiver have the necessary privileges or permissions to talk to one another. It could be the sender maybe allowed send, but the receiver may not want to accept from that sender or I mean it could be, it's a policy decision. It can be done a number of different ways and it can be very expressive and expansive as to how you want to perform that authorization. But of course, for that to make sense, you must have first make sure that you have the identity understood and established. Otherwise authorization makes very little sense. Now, the one thing I wanted to point out with authorization is it's fairly common in many service meshes. It's offered in some of the APIs, some of the APIs like SMI and stuff like that. But not necessarily is it available for all the, of all the meshes. Excuse me one second. I apologize. Sorry about that. And the authorization may be implemented either by the client side proxy or the service side proxy or both. So the final point that I wanted to make here is when we talk about authorization here and a lot of this talk, I'm really talking about authorization from the perspective of the service mesh. Obviously, both with authentication and authorization, the client and the service, the client and the server above the proxies may be doing all sorts of capabilities and functions of their own. In both of these areas. So I'm not covering those kind of details at all. So, let's see now I'm going to kind of move away from sort of the, the, a little bit less of the educational aspects and a little bit more into who's who's really doing these things and how are they doing it. So here I chose to highlight how linker D does its authentication architecture. So, and if Paul's fairly similar to that process that I described before, so the service account. If from Kubernetes provides the sort of provides the workload and identity and linker D the linker D controller will find a certificate with that based on that identity. And have it in a way that we can use PKI techniques to validate appear can use PKI techniques to validate it. And it does that via some of the certificate signing request and trust anchors that it's passing over to the proxies. And once that's all done, then the MTLS handshake can happen at the proxy level and the application is unburdened by the need to perform this handshake nor deal with any of the service account signing request trust anchors any of that. So it sort of freeze the application to be a lot more streamlined. So authorization architecture is sort of much the same. There's typically some kind of policy module in the service mesh controller on the policy module will push the config over to the side card proxies. And when it's expressing that config, if it's for these links in the middle, it can express the config, both in terms of the identity within the mesh that it's well aware of and has established so it's able to express this in a very clean, non ambiguous way. Whereas if it's doing authorization on either the ingress side or the egress side of a flow, it won't have the same unambiguous set of information. So it has to be expressed a little bit differently because the source identity would be from outside the mesh or the destination identity is within the mesh. So there's lots of different sort of capabilities and granularity that come in with respect expressing the authorization. So what I did to try to show this is an example from the SMI, the SMI API, if you will. And what this particular example, very, very simple example shows that you're specifying a destination identity via service count. You're expressing some ports that will be used in the destination and namespaces. Then you're preventing specifying a match criteria. And in this case, you're just referring to another API object. And that API object, in this case, HTTP route group can talk about the different HTTP paths or routes within the layer seven that should be authorized or prevented. So, for example, you can prevent certain, based on a certain URL path, prevent certain sources from going there while other sources can get there, that kind of thing. And then you also have the option of specifying the source identity. In this case, this example case that I grabbed, it's letting sources from the Prometheus service account access the destination. So now let's talk a little bit about SPIFI and SPIRE. So, as I said before, I kind of covered the first two bullets a little bit. And the SPIFI provides a framework to be able to bootstrap and issue identity services across heterogeneous environments. So it's really, because of that, it's really suitable for today's cloud-native applications. So it's really, in the way I'll show in a demo later, the way we kind of use it is because we have a very multi-cluster environment. And in fact, those clusters may not be all from the same security domain than maybe from different providers. So we want to be able to make sure we have a framework that can allow the security identity to still be specified clean and in a clean way and secure way. So service meshes are moving very quickly towards SPIFI. There's a lot of, you see a lot of sort of issues and PRs and whatnot moving that way. But they're not all supporting it in exactly the same way, nor are they all necessarily supporting all the aspects of SPIFI. So there's different levels of support or different portions of the SPIFI spec that different meshes will support. And the network service mesh, as I mentioned, network service mesh, I'll show in a lot of detail in a little bit how network service mesh is using SPIFI Inspire. But other service meshes that support parts of the SPIFI specification include Kuma, Console Connect, SEO, there may be more. I wasn't trying to be fully research the level of support here across the universe of service meshes. So when we talk about SPIFI, the key thing is the next bid. I'll refer to that a number of times before and it's based on the next 509 certificate, which includes the SPIFI identifier, which I've highlighted here. I hope I wasn't hiding part of my screen by the Zoom call if I did apologize. Difficult to get feedback from people who aren't allowed to apologize about that if I was. So here's the SPIFI format that SPIFI specifies. Now we'll talk a little bit about the architecture. It has a server architecture and agents. It has a workload API. By the way, this is borrowed from the SPIFI website. So these are all figures coming from the SPIFI website. So it has a registration API because there's a need to sort of register identity. I mean, not the identity, but register who you're going to be able to... Which agents you're going to talk to and how you're going to identify those agents. So there's a bit of a bootstrapping that's needed via registration API. But once that's done, then the server uses the Node API to talk to the agents. The agents uses the workload API to talk to the workloads. So by this means we have a way to both ensure that the workloads are who they are and that they're running on nodes that we know of. And it gives a full chain of trust along the... And a full chain of identity along in these sort of cloud-native environments. So here's some details on the SPIR design details. I mentioned the registration API. I mentioned the agents. And there's a bunch of different plugins that they have that the server can use. It can interface with an upstream CA. If it wishes, the key manager controls how it's going to store the keys and what kind of format it's going to use on the disk. It has some data store plugins for which data stores or databases it's going to store its data in. And then it has some node tests or no resolver plugins to deal with node attestation and also within different environments. So a tiny bit on the SPIR node agent design here. So we talked about the workloads. The workloads will call the API. I'll show that a little bit later. It has a node attester, a workload attester, a key manager as well, similar types of operations as I described on the server. There's different paths for K8 versus UNIX. If it's trying to do a workload attestation on the UNIX versus K8 environment. Here's an example of the flow. The workload will call the API to request its identity to be provided. The agent will do some attestation to ensure the workload is who they are and I don't want to get into all the details of the different attestations that it can support. But to keep it simple in the K8 perspective, it's typically the service account that we'll use. So there's some communication with K8 and Kubelet to get that service account and make sure it's who they make sure the service account that's applied is as expected. And I'll get into that a little bit in the demo here and then back provide the NSVid to the workload. So that's a little bit on Spit the Inspire. Excuse me. Now I'm going to talk about some of the different identity models that we have within Service Meshes. And this is where I'll introduce some new things that we are working on within some of the communities and also talk a little bit more and show what we're doing specifically with Network Service Mesh. So probably most of the audience is familiar with this. Nearly all the sort of Service Mesh multi cluster models have examples of the shared root trust. It's a simple model basically assume every cluster is able to get its certificates from a common root and all the generations happens through common root. There might be intermediates along the way but it's at least traceable back to common root. Pretty simple model but it sort of assumes that you have that sort of common trust domain that works for all clusters, all locations and whatnot. And that works in a lot of cases even in geographical distributed cases that can work but it won't work in all scenarios. So one thing that we've been working on with Istio and the Service Mesh community is something that I show here as a bridge trust. It's something that is just coming out in flight now in real time. And what it involves is where we actually try to allow sort of go forward a little bit. We basically allow this cluster to be entirely its own trust domain and MTLS within this cluster will be based on the native Service Mesh that's over here. Similarly, the native Service Mesh over here will have a different root different trust domain and be able to do its own thing but we still want MTLS in the middle so that's why we'll introduce the ability to provide what I label here as a trust domain between the ingress and the egress. So the way we do that is that the way the Service Mesh does it isn't changed. Each of these Service Meshes in the case that we've been trying out at Istio and Istio but it doesn't necessarily have to be. But these Service Meshes control their own certificate and identity management however they want to do it, however the client and the gateways talk or the server and the gateways talk we don't really get involved with. But then what we do here in this case I list the FNH or Service Mesh hub is kind of how we're doing it. We basically have our own set of intermediate certificates that we're providing to both the ingress gateway and the egress gateway to be able to provide that bridge trust that I'm labeling here. I won't necessarily kind of go through these one by one but the idea here is MTLS between these guys based on this Mesh's identity frameworks and then certificate frameworks then MTLS between these guys based on this intermediary and then MTLS over here. So you have MTLS all the way through but you're not forcing the client and the server to be to the same common root certificate. So there's some scenarios where this can be useful. So moving on and I know there's been a number of talks and presentations and some more various in a number of different cases for this model here where we talk about federated identity. And we've been spending some time on this although we don't necessarily have it all fully working yet but the idea here is that you have federated identity between, well I show it as this DOD here, but if the DOD or the service mesh over here it doesn't necessarily have to deal with it can sort of deal a little bit as its own trust domain and likewise over here but when this guy and this guy or gal want to communicate to each other they have to have a trust bundle that can include both A and B. So if this one's communicating over this way this one will have to have both a little bit of A and B so that it can identify this guy and then likewise identify this guy on that side. So the Istio has some capabilities right now to specify these trust bundles with, you know, pointing to basically pointing to a different SPIR server based on a domain. So based on a domain you point to a SPIR server that could be multiple disease and that allows Istio to provide a more complete trust bundle for with both the A and the B components. So now shifting a little bit back to NSM or network service mesh which as I mentioned before is more layer three and four oriented than the application service meshes but it's been in the forefront of adopting some of the SPIFI SPIR implementations and it uses the SPIR servers to provide the identity for the different network service mesh elements as they're communicating to each other. So it's the identity framework they use. There's an option if you're playing with network service meshes it's a secure and insecure option so you can sort of do it without this level of security but it's available and it's the security framework they use. So you may not be familiar with NSM but some of the key modules I'll talk about are network service clients, network service endpoints, network service registers and network service managers. In a way for the perspective of this talk you don't necessarily need to understand too well exactly what these do unless you are really interested or you know NSM but the key point that we're trying to show is how as requests get chained through these guys using the embedded network service mesh APIs for getting services and providing services that's the key thing in the API. As those requests flow between these guys I'll show how they use SPIFI SPIR to sort of make sure they're secure. It has a, the reason, the big reason that we, oops, sorry to put that. The big reason we're ever interested in this is because within NSM if you're familiar with the project or if you want to go look at it they have what they call floating interdomain use case. And the big thing about that use case is those API communication must cross multiple cluster boundaries and potentially as I said before as you're talking about crossing multiple cluster boundaries you potentially may have to cross into multiple security domains. So that's why I thought it was a great use case to display this SPIFI inspired capabilities here for this talk. So again, if you don't know NSM try not to worry too much about what the individual modules do here but the idea here is you'll have a network service endpoint having shown the workload or the ultimate client yet in this case and it's going to do a network service request to the network service manager and as we ultimately need to have connection between these two NSDs that are on different clusters for this particular network service request, there's a whole chain of API requests of a simple API but more than nonetheless a chain of API requests that go around and in the use case that I mentioned I'll demo later it involves three clusters sort of a client cluster and a server cluster if you will and then a control cluster but the details really matter. The idea is request, request, request, request, request, request. Now all these need to be authenticated and we need to know who each of these elements are whether the element is who they expect it to be and we want to use encryption along the way. So how does NSM do this? So here's kind of the architecture. You'll see that there's nothing really outstanding or kind of really novel about this architecture. I kind of showed it before but if we superimpose what I showed you just before, we have spire servers, spire agents. We have some search generation. In the case that I'm showing here, we're going to show a common root. I kind of was expounding on how that's a little limiting but nonetheless that's what the demo will currently show. And then I try to show, my key over here tries to show some of the ESFID propagation that happens and the MTLS exchanges that come along the way. So now I'm going to try to go into a little bit of a demo that unfortunately I chose not to do this real time so hopefully this all comes through in a recording. Let me go back here. Let me try to start the screen. Hopefully everybody's able to see this. But this initially shows the current topology that I have. And then I'm going to start showing you aspects of this topology. So first thing I'm going to do is show you, we have spire server and agents deployed. And it's not going to be on three clusters. You'll see slightly different naming. This is all based on kind. So for those familiar with kind, you'll see I'm using the kind API servers and using context. So we need to bootstrap the server. In this case, I create a secret. And you can see that I named that secret for spire. Now, because I said we're using a common root, I'm showing you here that all of the secrets the same. I just did a diff of getting the secret and the key parts of the secret are the same. And then via some other magic within NSM and spire, we actually end up getting a config map, whether it's a to fake it, that spire uses. And I also show here that that certificate ends up being the same in all the spire servers. So that was a little quick. And I'll just go back for a second. We just hold it there. You'll see that I'm getting the config map from two different clusters and showing that the key parts of that config map, the certificate itself is the same. I show the spire server config. This is where some of the config we put together, bootstrap it. You can see the secret that I created telling it where the name of it. And I created a trust domain here. I'm going to highlight all the aspects of it. And right now I want to show you that we don't need to do anything. And right now I want to show you that we don't initially have the endpoint or either the client endpoint or the NSC's registered. So my actual name here of my application is going to be hello. So I just crept in here so that there's no hello registration in the certificate right now. So now I'm going to deploy the NSC's. Now, again, the key thing for those not familiar with Network Service Manager, the Network Service element is a pod, typically a pod that provides some kind of network service or some kind of network function. And then I actually have Hello World pod in this case. Again, all the details are not that important since we're doing the floating inter-domain. Basically the details are I end up interconnecting these NSC's so these guys can talk. But I'm not really going to get too much into that detail in this talk. So we continue on a little bit. Let's get the NSC pods. I actually have two Network Service Element Pods running here. And what I want to show here is that we mount the socket in the NSC so that it can talk to the Workload API of Spire. So this is one of the key things to make sure that Spire can attest that this Network Service Element is where they are, say they are. Now I just showed the Hello Pod. And as part of this, in the background I don't show the actual steps, but we've actually registered with Spire that those Workload Service Accounts may try to connect to them and should be provided a certificate. So here's I show these two here. There's the NSC and the client itself. So now once that was registered, then these guys can get an identity from the Spire agent on their given node. So we're going to show a little bit of that here. This is let me just go back a little bit, run a little quick. So what I am showing here is the Spire agent on a particular one of the clusters. By the way, my clusters are single-node clusters so that's why I don't get into too much of the node attestation steps, but anyway, nonetheless. And what we show here is that the Spire agent did see a request from someone that has the Hello Client Service Account and it will go ahead and provide an Svid to it. And then we can look at the server and we can see from the server Svid that it's signed and rotating both because it took me a long time in between doing this and capturing it so you can see some of the rotation that happened in between. So now we're going to move on here and I'm going to try to show you a little bit difficult. This part is a little tricky to show well in a demo but I'm going to attempt to do it anyway. How each request in the chain is using MTLS. So I'm going to do that with some code snippets, Jagger tracing, and some logs. So the first thing let me just pause this is that this is from Network Service Mesh itself. This is a trace point for Jaeger. Since a lot of this code is done by libraries all I want to really show is that we hit this trace point because you can see that immediately we're going to go and get a TLS config for that based on this GeoPC server call. I think I'm going to have just enough time here. So let's look at some of the logs to try to see this. So if we look at the old container log, this is from the client or server side. If we jump down here we can see here the two key lines I want to show you here is right shortly after this came up because this is from the init container it actually got a certificate issued from Stiffy and it then it created the connection. So these are like bang bang right after the initial initial patient happens it starts trying to do a communication with the server and it's establishing its identity. And so I'm going to try to show that Jaeger is actually capturing some of this. So Jaeger NSM has some nice ability to install Jaeger and it looks some traces. Sorry about the six hour delay but it takes a while to make sure everything's running properly and capture thing and go through work distractions in between. But you can see here the key thing I was trying to point out before is that got certificate trace point was hit by this code. With that we've been able to sorry, back to slide decks pretty much done. The only thing I wanted to say is I got a lot of help from various people to get this done so I wanted to acknowledge them and then that's it except for questions. So Jerry how do we want to do questions? Well thank you John for a great presentation. I'll read off the questions to you one by one in the Q&A box. We have about five minutes left so if anyone has any questions that they would like to ask please put them into the Q&A box and we'll get to as many questions as we can. We do have one here. Would similar authorization architecture work for STO and Envoy based service mesh implementation? Yeah absolutely STO is one of the service meshes that actually allow authorization within as part it has authorization capabilities within the API and within its control plane and how it pushes it down to Envoy. Envoy itself definitely has a lot of capabilities in the authorization vein so Envoy no matter where it's used has those capabilities but the service mesh that's controlling it some do some don't. Now in the example I gave for authorization I used an SMI API object I'm pretty sure STO doesn't support the SMI API objects themselves they have their own API objects but they do support authorization capabilities similar to what I showed. We have any more questions at all? Okay great I guess with that thank you all for attending. Hope you all enjoyed it and hope it all came out pretty good it's hard for it without feedback to see if everybody was able to see everything that I hope they saw or care me well enough but hope it worked out well for everybody. There's one more question here there is a VWIRE on one of the slides would it be possible for you to elaborate a bit more on that? Oh okay not sure exactly oh okay on this slide Yeah that's not to remain to what I was trying to show here but I'll since I have a few minutes I'll talk about it but network service mesh VWIRE is a key construct within network service mesh itself so network service mesh the main if you're not familiar with it at a macro level what you have is you have network service elements that provide a network service you have clients that I don't show on this page I show on the other thing that might request a network service mesh and then the NSM manager wants to connect those clients to the network service. Now in this particular example since I'm using what's known as a floating inter domain network service the network service actually has to span across clusters so essentially a better way to show this if I can find my arrows is maybe I'll stay with this one. So a better way to show this is that for this particular network service I need a VWIRE from the NFC to the client which I don't show but I assume it's there and then I'll need VWIRE from the forward or across the cluster boundaries I'll need VWIRE from the forward or to the NFC and then I'll need another VWIRE from this NFC to the server side. So essentially a network service mesh is using what the construct called a VWIRE, a virtual wire is how it's actually choosing to interconnect a client's request for a service with what that service entails. In this case the service entails crossing cluster boundaries. Okay well it's just about all the time we have for today. I want to thank you again John for a wonderful presentation and I would like to thank everybody for their questions and for participating in today's webinar that's about all the time that we have as I said before the recording and slides will be posted later today to the CNCF Webinar page at cncf.io slash webinars. Thank you again everyone for attending everyone take care stay safe and we will see you with the next webinar Okay bye