 So, there we go. I'd like to thank everyone for joining us today at the CNCF live webinar, securing your workload communications with open service mesh. I'm Libby Schultz and I'll be moderating today's webinar. I'll read our code of conduct and then hand over to Phillip Gibson, Senior Product Program Manager at Microsoft. A few housekeeping items before we get started. During the webinar, you're not able to speak as an attendee, but there is a chat box on the right hand side of your screen. Please feel free to drop all of your questions there and we will get to as many as we can either in the middle when it's pertinent or throughout at the end. This is an official webinar of the CNCF and as such a subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct and please be respectful of all of your fellow participants and presenters. Please also note the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. They are also available via your registration link and the recording will be available on our online programs YouTube playlist. With that, I will hand it over to Phillip to kick off today's presentation. Alright, thank you, Libby, for that intro. Welcome, everyone. Thank you for showing up. I think we got a really good session today. We're going to be focused on really around securing your workloads, communications, how you can actually add a little more security or strengthen your security posture with your Kubernetes cluster. So our agenda is going to look like this. So I get the slides moving along here. We'll do a quick overview of OSM for those who may not be familiar with the service mesh. And then again, this is going to be pretty demo heavy. I got some recorded demos here that are probably newer than what you've seen out there. And I would have done this live but again, we want to make sure that there's no network disconnects, etc. But this is the demo list. We're going to start off doing our traffic access demo and stay tuned for that. We'll talk about it. We're going to build a little storyline around some of these demos leading into the next integration. And then after that we'll talk about the OPA integration. And then we'll move on to our contour integration. So to allow you to do true end to end encryption from TLS to the back end in TLS workloads in your environment. And then we'll finish up with the egress workloads, how you can actually control what your pods are communicating to outside the cluster. So I'm excited about this. A lot of these integrations here have been driven by the community. They've actually were things that we kind of put more priority on in the backlog. So thanks to all those who participated in letting us know the use cases that you're most interested in. So OSM, this is probably the newest service mesh in the community. We open source around July 2019. And our core principles have always been to provide a very simplified experience for most common use cases of a service mesh. We're not into the speeds and feeds race. One thing that we do feel really good about OSM is we are using a very tried and true data plane, which is the Envoy proxy. And so a lot of our backlog is really about just opening up a lot of the Envoy functionality in a very elegant way that is very simplified for the operator. So again, these are kind of our core principles being simple, effortless to install, maintain and operate painless to troubleshoot. And again, easy to configure a VBSS my specification, which if you're not familiar with that specification. This is kind of a abstraction layer, you know, for service measures, so that consumers of service measures can really experience a simplified API integration experience with their apps tooling and everything else. So this is a growing ecosystem and we look to really build out a lot more functionality in the original spec for. So if you have any questions or want to know more about the SMI spec, you can go to SMI dash spec.io and you'll see a lot of documentation on the actual spec itself. So with that, let's go ahead and jump into our demos. I'm a visual guy so when I do demos I know it's a bunch of, I like to say it's a bunch of text flying back and forth so I keep my PowerPoint animation skills going here where I kind of give you a preview of what you're going to see in the actual demo itself, right. So what we're going to do is we're going to do the traffic access demo. And again there's going to be a little twist at the end here we're going to build upon a story and then you can see if something like this could exist in your environment as well. But we'll start off with deploying our book buyer and our bookstore demo application will have OSM installed enabled to manage both the book buyer and the bookstore namespaces where those applications are deployed. And then we have this permissive traffic mode being true which means that you know we're going to pass traffic through the envoy sidecars but we're not going to require any additional policies. So this allows you to easily kind of onboard your environment and then figure out which policies that you want to really mandate who can communicate in the mesh itself. So once we do that. Obviously, you know we have the envoy proxies and then everything's going to run smooth at this point. We'll turn it to false and then again we'll deploy our policies out there. And then you'll see that the book buyer will still be able to communicate to bookstore v1 service there. Actually, I got ahead of myself. Actually, when we flip the permissive mode to false. That means we're going to have to have a policy will then create that policy to pull it out into the cluster. And then that's going to resume our communications back for the bookstore application. Now here's the twist right, we have our service mesh. We have a explicit policy allowing book buyer to only speak to bookstore v1. That's really kind of what you're going to want to use a mesh for this is all mtls. You know encrypted but on top of that we actually have a specific policy saying that book buyer can only speak to bookstore v1. But what if someone in your environment goes rogue right. What if one of your operators goes rogue, you know, so what if we spin up a new service, maybe you know about it maybe you don't. And you have again, maybe this is a rogue admin who has been paid or knows who this application is, and what's stopping them from allowing the book leave to talk to the bookstore. And again, you know, as we progress through all these demos you're going to see how we can kind of, you know, thought some of this type of activities in your environment and you'll see how easy it is for an admin who has permissions to do so be there being able to allow this type of activity. So let's go ahead and get into the demo itself. We're going to start off, and we're going to create our. We're going to take a look at our pods here. I'm not sure why that. Okay, pretty button. So first thing we're going to do is we already have our book buyer, or the bookstore application deploy so we'll just take a look at those pods itself, and you'll see that we have our book buyer bookstore book warehouse all deployed simple three tier kind of Microsoft application. And then next thing we're going to do is we're going to look at the list of all of the namespaces that OSM is currently managing to provide service mesh functionality so you'll see again, the buyer bookstore warehouse all enabled. So everything is good there. Next thing we're going to do is we're going to take a look at the permissive mode the current permissive mode. So just the book by you'll see it's two of two so you have your application container alongside your ongoing sidecar proxy as well so everything is all configured. So now let's go ahead and just take a look in the query and see what our current status is for permissive permissive mode. It is set to true. Again, that's going to allow us to pass traffic with no explicit policies in the mesh. What we'll do here quickly is we're going to query on to the book buyer pod, and then we're going to this logs and just verify that it can speak to our bookstore be one service here. And so our standard out the way we're formatting this is you can see it's hitting the bookstore endpoints. That traffic is traversing through the on boys sidecar proxy we're getting 200 okay so at this point everything's okay book buyers able to speak to the bookstore and purchase books. So next thing we'll do is really again what you want to service mesh for is to kind of control the levels of access going on inside your cluster. We're going to go ahead and change the permissive mode policy here or setting we're going to patch this over to be false. And that's going to instruct the OSM controller to ask for specific routing rules or traffic access rules to allow traffic to happen inside the mesh. So as soon as we do that, we can go back and tell the logs of the book buyer, and you'll see that instantly that traffic has been stopped. You can no longer communicate to book for the one service. And so that's that's great. That's what you want to service mesh for. Next thing what we'll do is let's go ahead and just allow the book buyer to speak to the bookstore. So we got an explicit rule here. I won't go into the manifest this is all kind of public here it's on our repose but essentially this is saying hey book buyer can speak to bookstore if you want service. Once that's deployed again we can go ahead and tell those logs and we see that access or the communications has been resumed from the book buyer being able to talk to the bookstore. So great. That's, that's what we want. So here's where we get a little, you know, things get a little interesting right so this is kind of some of the rogue activities that could happen in your environment. So we're going to go ahead and create a namespace for book deep. And we're going to then add that namespace to OSM to be able to manage so we're actually going to bring that namespace into the mesh. And then we're going to go ahead and deploy the book the service or application and again it's going to want to speak to the bookstore service. We're going to go ahead and deploy the books as a thief would want to do. And so right now, our policies are only allowing the book buyer to talk to the bookstore. So if we go ahead and tell the logs off of the book thief. We should see that it's going to be blocked because there's no explicit policy allowing this activity to happen. And there you go. So at this point your message is protecting you right you have a new service in the mesh. There's no explicit policies to allow so. But your bookstore be one service is protected. But what if you get somebody who's going to go rogue right you have an admin or an operator who has the permissions kind of override this activity. Maybe your RBAC is not in place here so what you're saying here is hey here's an operator they have permissions to do so they're going to go ahead and edit actual traffic access policies. And they're just simply going to add the book thief to the manifest and allow it to then talk to the bookstore. And so again this is on the fly so this kind of goes around any CI CD process, etc. It's just on the fly editing, allowing the book thief here we're just going to add the kind here which is going to be the service that represents book thief. The name itself which is going to be book thief. And then the name space that the beef lives in, which is again, we can make this real simple everyone. And so again on the fly editing, as in most operators may have the opportunity to do so or the ability to do so. We'll save that out. Okay, so we've added that traffic access policy. Let's now go ahead and tell the logs of book thief. And voila, it now has access to still books from the bookstore. And so again, you know this is really the show that, yes, a service mesh can protect you, it can actually give you the encryption that you're looking for but again it's not a one stop shop and really securing your cluster of things that you're going to want to look into and investigate to really heighten up your posture of communication scientific cluster. So, how do we get this rogue admin to not, you know, turn things on that shouldn't be on. The next thing you're going to see is our OSM OPA integration, and this is really the extension from on boy, which allows on boy to actually have an external authorization. You know system or policy to really, you know have an additional set of guards or gates to ensure that you know your policies are what they are. And so what you're going to see here is again, just as just as we left off book thief is stealing books from bookstore. And so what we're going to do is we're going to deploy OPA if you're not familiar with the open policy agent this is basically a project around policies for Kubernetes. And in this instance here, I do have OPA deployed in the same cluster just as a demo. Most likely in your environment you're going to want to have OPA deployed outside of the cluster somewhere that where there's more guarantees of who has access to implement policies in your environment. So we'll deploy OPA. And then what we're going to do is we're going to have this policy and we're going to tell OPA that hey, only the book buyer can talk to the bookstore. We're going to deploy that. Now again that the local OSM traffic access policy is still allowing the book thief to talk to the bookstore. But now we're going to have this additional check this additional external authorization provider to ensure that our policies are correct. So we'll have that deployed. And what you what's going to happen now is is part of the communication handshake is both book buyer and book thief now have to go to the OPA and say hey, or do you have a policy for me to be able to talk to the bookstore be one. We're going to configure the OPA policy to allow the book buyer to speak to books or be one, but we're not going to have a policy that's going to allow book thief to talk to bookstore be one. So you'll see that this is a way that you can actually control some of the activities going on in your mesh. So let's go ahead and see that in action. And I'll go ahead and we got the play button going. So again, let's just verify the OSM traffic that's happening here, we're going to take a look at the book buyer. And we're going to again just tell us logs and ensure that they can still talk to the bookstore service. Again, it's happy. This is normal. We're then going to go and look at our book thief part. And we're going to tell it's standard out and see if it can still talk to the still still books from the bookstore service. And it can because again there's a local traffic access policy that allows you to do so in the mesh. So what we're going to do is let's go ahead and set up this external provider that's going to actually give us an additional gate of authorization inside the mesh itself. So we'll go ahead and we'll create a namespace for OPA. And then we'll deploy the OPA application in that namespace. And then here's where our integration is so we have to edit our OSM mesh config. And we're going to go down and we're going to basically tell the mesh config that hey I want you to also use this external provider being OPA. So what we got to do is we got to turn that on first we'll turn it to true. And then we just have to give it the address to the endpoint of OPA. You know, that's going to be your policy engine that. It's port itself. That's going to be port 9191 default ports for open policy agent. And so now again what we've instructed is again the envoy extension in the sidecar to say hey, don't just pass the normal OSM local rules actually go out to this provider as well and validate that those rules exist. So, well, since we added this external provider, all of the communication is stopped in the mesh, because we have no rules and OPA at this point that's going to pass anything so it defaults to false. So you'll see that we got a status 503. Don't mind some of this other standard out we got to fix some of the way we were logging this but we basically looked at both the book by in the book they can access anything. So, now let's go ahead and edit OPA and give us some rules that's going to allow just only the book buyer to speak to the bookstore. And real quick we're just going to look at the logs coming out of the OPA. If you're familiar with this there's a bunch of decision IDs it's kind of computing everything and you'll see that in those attempts everything was a false. So that's why none of the book buyer or the book thief was able to speak to the bookstore service. Let's now. And again, we're just verifying here that your local OSM service was policy is allowing both the book buyer and the book thief to speak to bookstore service. So next what we're going to do is we're going to now create this OPA policy. If you're familiar with the the rego template we're going to say the, you know, for bookstore. We're going to do a get request to that path book spot, and we're only going to allow the book buyer. And there's a couple of end points so we also need to get the get new book in point but this is essentially the policy that's going to be configured for OPA to look against all the lookups that are coming from on boy to it. And so we'll go ahead and deploy that. And we simply just have to do a restart on OPA so it picks up that configuration. And so now that OPA has this policy. Again, in addition to the local OSM policy, say, Okay, yes, I'm going to allow the book buyer to speak to the bookstore. You can see that the communication has been resumed. And again, this is an external authorization provider. And if we simply again look at the book thief, you'll notice that it is still blocked even though there's a local OSM policy that says the book thief can speak to the book, the bookstore, that extra hop going back to OPA to validate those rules is prohibiting the book thief from speaking to the bookstore. And we're just simply going to just look at the decision law coming out of OPA and you'll see that the results are true for the book buyer speaking to the bookstore. So again, this is another way that you can actually have heightened security and extra gate of security here in one of these very secured environments ensure that your local operators cannot change anything going on in the mesh. And again, this OPA answers can be in a different cluster that has a whole different set of RBAC rules that your normal operators do not have. Okay, so that is the OPA integration. All right. So this next integration. And we get a lot of questions about this. We were asked many times if we were going to actually build a specific ingress for OSM and we kind of look to see kind of what was out there in the community and obviously contours are very well known and trusted ingress and so we actually worked with the OPA team to actually bring that functionality into OSM. And so we believe this is a really good kind of collaboration inside the CNCF community. And so what we're going to show you what you can do with contour is a lot of things really around the ETE full encryption from your TLS to the MTLS back end. So what you're going to see here is we're going to have we already have we're going to have our contour ingress deployed. We're going to deploy a sample app. This is the HDTP bin app here, because we're going to test some of some things a little later here but so we have that app deployed. And then with contour which what you can do is you can actually put a policy to say hey this ingress is only allowed to talk to this back end. And at this point you're already securing the communications between the ingress to whatever back end workloads that you have. So again if you've not identified this or configured it, any other service in your cluster that ingress will not route any traffic to. So the policies are very fine grain. So what we'll see here is just standard HTTP. You're going to have an external client be able to hit the contour ingress and then get access into our application here. Now, beyond that, again the question that we get to say how can I get full ETE encryption, you know from my external clients coming into the ingress and then back to our back end workloads. So what we're able to do is we're able to share the CA bundle that comes from OSN, and we're able to take that cert, put it on to the contour ingress. And then that's going to allow us to basically pass off the TLS encryption to NTLS to the back end. And so you will essentially will have a true end to end encryption path for that communication that's happening. And so that'll all check out here. Next thing we can do is, again, we talked about, you know, really authorizing the ingress to talk to back ends, etc. If we ended up renaming this ingress to a different name that's not a CN name for the ingress to talk to the back end, all that traffic will stop too. So those certs are very specific to those running instances in your cluster there. And so with that, let's go ahead and show this in action here. We're going to just export some variables for some downstream, some downstream configurations that we're going to need. So we'll look at the OSM list. So currently, right now we just have the OSM system. We're going to now deploy, or we're going to look at the service for Envoy in that OSM system. You'll see that we have Envoy, I'm sorry, not Envoy, contour have been running as a low balancer. So our ingress is live. And then what we have to do is to restrict the traffic, we just have to create a annotation there for the namespace itself. And for some of the commands downstream, I'm just going to go ahead and grab the IP addresses of the actual ingress itself. And then we're going to deploy our sample application. So we're going to go ahead and create the namespace for the HTTP bin app added to OSM to manage that from a service mesh perspective. And then we're going to go ahead and do the deploy for that application. And then let's just get an enumeration on those pods for the application. You see we're up and running with 202 application pod. I'm sorry application container as well as the Envoy sidecar. And then our service endpoint is up and running. So now we're going to go ahead and create the contour ingress specifically for this back in service. And this is all upstream integration. So if you're curious, hey, how do you set this up? Simply visit the contour project site. All of the documentation is completely applicable here. And so we got that ingress deployed. And now we're going to do we're just going to test the application from an HTTP standpoint. So this is not HTTPS, but that's coming across is okay. So our external client is able to access that back in service. And now we will actually configure this to be full true into an encryption. We'll go ahead and annotate the service here for the TLS. And then we'll create the contour proxy here. That's going to make sure that the back end will be TLS as well. So you'll see there's an attribute here if I keep scrolling for the protocol to be HTTPS. Okay, so all of that's deployed. And I mean, you won't see anything like magical here other than us getting okay that the traffic is happening. And this is actually representing true into an encryption from the TLS to the ingress and then that being translated over to MTLS on the back end and everything comes back. Okay, here. This next set here, we're just going to verify that unauthorized sources can't access the back end here. Again, we're going to kind of change the, the name of the ingress. And since we've changed the name of the ingress, that ingress is not allowed to talk to the back end. So again, if we do that curl command again coming from external client, you'll see that this is all forbidden. So no traffic stable to pass through in the ETE scenario here. And then we can validate the client access here as well. And if we wanted to, we can actually skip all of this. If you wanted to kind of just, you know, if you were testing or something of that nature, we can go ahead and just say, hey, don't force those policies. We'll get that deployed and then we'll do the simple curl command from the external client again, and you'll see that it will then be able to speak to the, to the back end. All right, so again, ETE encryption. I know that's highly desirable. And I know we had a lot of people in the community asked us how to do that. And we're able to do that with our contour integration here. All right. So next, what we want is this isn't really an integration but this is just a feature that we have which is really controlling the egress in your environment. So you may know or you may not know what workloads are being deployed in your environment. They could be reaching to known endpoints or they could be going to endpoints that you don't want them to go to or unauthorized endpoints. So here's a simple way that we'll look at some of the configuration that OSM allows you to do to actually control the egress communications of the podge and all workloads that are being deployed in your cluster here. So first thing is permissive mode is false. So again, we're going to be asking for access policies to to have traffic pass in the cluster. We do have this notion of the global egress being true. So by default, when you deploy anything, we're going to just create a simple curl application will create a curl name space will deploy the application. And by default, we're going to allow your workloads. In this case, this pod to just be able to leave the cluster for communication will just be able to hit this endpoint here with no issues. And that may be fine for you. But again, if you want to ensure that you know about all of the exit communication in your cluster, you may want to investigate and look into these egress rules that I'm about to show you here. So next thing we'll do is we'll flip the global egress policy to false. And what's that's going to do is that's basically going to lock down all the communication of your workloads trying to exit, exit the cluster itself. And so what you'll see here is immediately we'll go ahead and check into this curl app and it won't be able to exit the cluster. And that's a good thing. So now you're going to get into really fine grain controls of which parts in your cluster that you wanted them to have access to exit the cluster itself. So with that, we'll go ahead and create a specific fine grain policy that's just going to allow only the curl app to actually exit the cluster. All other workloads will still be confined by the overall global policy here, which is going to stop all the traffic here. So once we do that, we'll go ahead and flip that. And then so again, we got something specifically saying that yes, the curl app can actually access anything outside the cluster. But again, any other application or workloads running in the cluster will then need their own specific fine grain access policy for egress. And so now let's go ahead and show that in action. So we'll start off. We'll just query the OSM mesh wide egress policy. And again, that'll come back as true. So we're going to allow everything outside the cluster by default. Now let's go ahead and set up our testing app, which is going to be, you know, a curl app. So we create its name space, we'll go ahead and add that name space to OSM to be able to manage. And then we're going to go ahead and going to go ahead and deploy the curl app itself and get that deployed into the cluster. Now that we have the curl app deployed, let's go ahead and just exact into it and then just issue a curl command out to this endpoint here that's outside the cluster. And that comes back as a 200. Okay, so again, this pod is able to exit the cluster and hit that endpoint. And now what we'll do is we'll go ahead and disable the global egress policy. So we'll turn that from true to false. And here we're just going to just verify that that changes happen. So we'll just query the setting there and we're false. And so now let's go ahead and do the same curl command here, we'll exact into that running a curl pod. And you'll see that it can no longer exit the cluster. So we've actually controlled or basically just turned on the setting that says nothing can actually exit the cluster itself. So now let's go ahead and then configure fine grained policies to allow just specifically this curl application to exit the cluster and nothing else. And here's our specific egress policy that is specific to that curl workload. And so that's been deployed. And now we'll issue that same command again, we'll see if we can curl out to that specific endpoint. And you see that it can. And again, with that egress policy, it's very specific to the endpoint. So that curl app couldn't hit any other endpoint that has not been identified in that policy. So again, you can get very fine grained controls using this next thing we'll do is we'll just show you us removing the policy there. And if we go back and issue the same command, it can no longer exit the cluster itself. Okay, so there we go. So that is egress. So that's kind of all the demos hopefully you saw something that it may inspire you to do something and actually heighten your security posture. Next, what we'll do is we're going to just talk about some of the things that are on the roadmap for OSM coming up here. We actually last week or so at coupon. We made an announcement. So we actually have our V dot 1.0 dot RC. That's all available. And the stable version of that is going to actually be available here really soon. Next, we're talking about expanding the SMI functionality. So again, those familiar with that specification around really building this abstraction layer for service measures. We think that there's more things that on boys doing that we can actually bubble up into that spec to make it more easy to access some of those features such as, you know, retries and circuit breaking, etc. There's a big initiative going around for that. We're also looking to expand our VM support so being able to bring things outside of the cluster to the match itself. And we currently have some things that are experimental. And so this is out there as well. So please check that out if you want to see how you can bring VMs into your cluster, as well as multi cluster support that's been probably one of the hottest topics as of late. People want to be able to actually extend these functionalities is cross playing controls across multiple clusters. And so we do actually have that in beta. So if you want to kick the tires on that, please go ahead and go get the latest release and you can test that out. As well as windows container support. So we got on boy supporting windows now, and we actually just did a demo at this coupon North America showing container support in OSM. And so we're happy about the direction of where we're going with that because that's going to basically open up a lot more workloads that we have customers asking for to be secured by service mesh. And then last just wasm wasm filters extensions. You know, there's a lot of activity around the whole wasm space. And so we actually have some of this working and we're actually looking to the community to give us a little more feedback on some of the filters or just wasm support they're looking for in the cluster itself. All right. So that's it for the roadmap. I've not been looking at the chat here, but I think we got enough time here. We'll open it up for questions if you have them. Please anything that you see you need me to verify or clarify or you just got any general questions about the OSM project itself. I don't know, Libby or I see Bridget you on the call. I don't know was was there any questions. I'm not sure. I guess there's no questions. All right, thank you. Hopefully, I don't slaughter your name you georgias. Thank you for showing up. Thanks. See you Bridget. Okay, yeah, no, no specific questions. Yeah, if you want to get involved, please go out to open service miss.io. That'll be a link to the actual GitHub repo. There's tons of kind of first issues that you can get involved with. So, yeah, and then we also have our monthly OSM call. I don't have the exact dates but if you do want to kind of meet some of the maintainers, myself included, you can actually come to those calls and again, there's things that you're looking to see happen. You've got certain use case that you don't see OSM being able to handle. Please show up to those calls. Let's just have a conversation about it and see if we can include those use cases that we may have not thought of. Okay, I see things are flowing into the. Yeah, so the question does OSM throttle connection request. Not at this time that is something that's in our backlog. It's basically something we would do from the envoy level. So, as I mentioned earlier, we are using the envoy proxy data plane. So, you know, we can basically tap into everything that always doing. Again, our purpose here is to kind of make those configurations super easy. And I believe we do have that as part of our backlog again with circuit breaking and retries. So, you should see that in the product or the project soon. Okay, we got a question from satish is OSM CLA dependency or can everything be done. Yes, you will need the OSM binary to interact with the OSM control plane. And so that that's much in line with all the other measures out there, they're going to have a very specific binary to configure the service mesh. So, yes, so the answer is yes, you'll need to just simply download the OSM binary. And then we have all the documentation how you configure the service mesh. If I missed any. Thank you Bridget for adding the community, community call dates and times. Do you provide integration for monitoring. Answer is yes. So, there's a couple of ways you can achieve this with the open source itself, we do have integration into, you know, for medias and Grafana. So you're able to do some monitoring in that way. OSM will also be provided as an add on to the AKS service in Azure. And once we're on the Azure platform, there's a lot of things we can tap into so there is integration with Azure monitor as well. And in future integration with app insights to actually draw up a lot of some of the distributed views as well. Do you support egress in TLS. So if you're egressing out of the cluster. Who's ever going to support that is going to be on the other end so whatever endpoint that you're configuring so you did see that we configured ingress coming into the cluster via contour. And so we do support again, TLS over to M TLS into encryption, but anything you're talking about that's going to go outside the cluster at that point you become the client and it's going to be on the servicing side and if they're going to support any encryption for you. Hopefully that answers your question there. Satish. Right. Anybody else. Okay. Yes, thanks for an inversion will be ready post event. Thanks. Thank you all that showed up hopefully you saw something new and excited to try it in your environment. Again, go ahead kick the tires on this. You got any issues. Again, go to GitHub, post your issues. We're on it. We got our maintainers are looking at those cues quite often so. Yeah, feel free to give us some feedback on anything that you've seen here today or anything else that you see in the documentation to try out. Thank you so much, Phillip. Thanks everyone for joining us. The recording will be up online later today. You can access it through this link for registration or on our YouTube playlist. And I think that that is it but thank you so much for your time. And we will see y'all at the next live webinar. Thanks everyone for joining us. Thank you.