 Now I'll start, Megan, thanks for being here, for letting me be here. My name is Clint, I work for a company called Net Foundry, and we sponsor this open source project that's called OpenZD, and the little guy here in our little right hand corner of the screen, that's Ziggy, he's our mascot. Okay, so why are we here today? Today we're going to learn a little bit about Zerotrust, take a look at what the current design is for most networks and why Zerotrust is so much better, see how you can add some Zerotrust into your applications itself, and then we'll see what does it mean to actually use the ZD, the OpenZD project. So this is the current networking setup that you're probably very familiar with, is this design that's kind of centered around castles and moats. So let's start off by just taking a look at a basic network. Maybe we have a corporate location in the lower left hand corner here. We have some cars that have some IoT devices on them, they use cellular networks. We have users, regular users themselves who are using cell phones and connecting through wireless networks that way. We have people who are at their houses, connecting their laptops or tablets or devices, all that sort of stuff, basic overview of a normal network. For our purposes, it doesn't matter if it's wireless or wired, those are going to be treated the same. So now I've replaced the design with a cute little castles and drawbridge is represented by a firewall. So basically reproduced the whole entire network, but substituted our imagery. This is what you'll see referred to as a wall and a moat design where you have traffic that is acceptable as long as you're inside the castle walls. Just by being inside of the castle, by getting across that moat, by getting over the walls or through the walls, I suppose, you are considered trusted. I think everybody who's attending this webinar probably knows this is a really bad idea. It's really never been safe and really never was and hasn't been for a very long time. So what sort of work did people do in order to try to make this situation a bit better? Well, the first thing people would do is they would try to put TLS everywhere or transport layer security. So if you've gone to HTTP websites and HTTPS, that would be an example. And that was a good idea, right? So we add TLS everywhere. That's a good first step. It starts our defense in depth. But I think everybody realizes that's probably not good enough. And even this was no longer considered good enough for quite some time now. Here's a couple of projects that we're trying to bring secure communications to the world. So we have the browser plugin. It's called HTTPS everywhere. I already mentioned HTTP, which is an insecure protocol, inherently insecure, just like FTP is. And so HTTPS was trying to make the world a better place by automatically upgrading you from an HTTP connection to an HTTPS connection. And this is useful back in the dark ages before everybody decided that TLS everywhere was a good idea. And it was so successful that and TLS everywhere is so successful that the EFF has decided to stop supporting HTTPS everywhere because today's modern browsers all just do this for you for free. So it's kind of antiquated, which is great. Then there's Let's Encrypt. Hopefully everybody is familiar with Let's Encrypt, but it is a certificate authority, a nonprofit certificate authority, trying to make it easy, which is important and free for people to get actual certificates, which are trusted, PKI and is a complicated subject. But right now, if you have a certificate, which is not signed by a trusted authority, then almost all your tooling will let you know that it's untrusted. You've probably seen this is an untrusted site message that your browser pops up. So here we are. We have an attacker that has gotten behind our castle walls. They've breached our moat, they have gotten over the wall, and now they are on our internal network. This is obviously a bad idea because now this attacker, since it's considered trustworthy by just being behind the castle, is able to attack any device that it wants to. So in this case, we're going to compromise that laptop in the right-hand side of our network. It's going to be the one that we keep attacking. So you can keep an eye on that network or on that device. So how did this happen? Well, it happens a lot of ways. Even if we're using TLS, that machine might have a very weak password. It might be susceptible to brute force types of attacks. It might be available that it's just running an old or antiquated version of TLS that is no longer considered safe, weak, easy to break ciphers, et cetera. You never really know exactly how. But attackers are nothing if not very determined. In case you haven't realized it, this is exactly how all of your VPNs work. Probably with COVID, everybody has used a VPN in the last two years. If you haven't, it would be, I think, frankly, amazing. But this is the way a VPN works like one gigantic drawbridge or one gigantic moat that you have to get over. Once you're on the VPN, you are considered safe and you're able to do that traveling horizontally, like we showed before, where getting on the network itself gives you access to these machines. So what did people do next? Well, the next thing people would do is they put a little guard and they would segment their network to the light blue and to the dark blue network. Obviously, that's a good idea. But what happens? Oh, sorry, actually, that's a good idea because traffic is now stopped by this guard. So we can declare victory. We don't have to have any better security. We're done, right? Obviously not. This is what I was getting at before. What happens when one of those laptops actually needs to be on both networks? Well, you've made the job harder for the attacker now, which is fantastic. But attackers are absolutely resolute. They're going to keep at it until they figure out that they can compromise a different machine and then use that machine to get to the target. Maybe this is a QA person's machine, or maybe it's a developer who actually has to have or an essay, right? They have to have access to these networks. These are common problems, even in today's best of practice network worlds. So let's take a look at how some zero trust concepts can actually help us with this sort of these sorts of problems. We can't go through all of zero trust. So I've picked a couple that I think are, you know, the most interesting pieces of the puzzle. I want to get rid of the network design. So we're back to our regular network overview. And now we might say, you know, how how can we improve this existing networks security? Well, what if we take the same idea that we had before of a castle and a wall or in this case, which can use the imagery of a firewall and we'll consider it, we'll call it the device's identity. So now what we have done is we have made our network so that it is familiar with who is actually trying to attach that network in order to get on to the network. You need to have a strong identity. Where did that strong identity come from? What is what is a strong identity? Well, we have a great set of articles that one of our top engineers wrote that shows you basically how the OpenZD project goes about bootstrapping trust. It is a relatively complicated project process. It does involve that PKI stuff that I talked about. It is using X509 certificates. This is the actual flow that the OpenZD project will follow. If you follow it along, it does make sense. And excuse me one second. If you follow along, it does make sense, but there's a lot of devils in these details. So we can come back to this later if we want. One question did come in. Why not remove the attacker from the connection? It's a great question. That would be one way of doing it. However, if the user or if the attacker is able to access both networks, then there's no way to know if that person should or should not actually be on that network, not at least without a strong device identity. And that's where we're going here with the device identity. So now we have that attacker. The attacker has somehow gotten on our network in classic terms. This would be just plugging into the network at some corporate office. You come for a presentation or whatever and you just use the ethernet jack and you jacked in with a strong device identity. The network actually realizes that you are not allowed to be on that network and stops the traffic before it even gets on the network, which is sort of what the question was asking before. Fantastic. That's great. Right. Again, we can declare victory. We foiled the attacker can't possibly go anywhere from here. Of course, not the case. Now that now this attacker is frustrated, but they understand, oh, I've got to do more work here because this is a bit more secure environment. I now have to go and specifically target one of these other devices and attack those other devices. So that's what this attacker did. It went out, it found a laptop or dropped a bunch of USB keys in the parking lot, hoping that somebody would put it in. And now all of a sudden you have an attacker who has compromised the A laptop, which does have this strong device identity. And now the network will allow that device on the network. And the same thing happens again, where that attacker attacks the same laptop and compromises that laptop. So even with strong device identity, you can still get compromised. Next, we come with a concept of least privilege. What if our network now understands not only strong identities, but also understands which those strong identities are able to attack whom? So in this case, we've got our attacker again, they've compromised that same laptop, and now they're going to try to attack the same target that they've been trying to attack all along with least privilege involved. Now, the network understands that the device that has been compromised is not allowed to talk to the computer that is being attacked. So because you have a strong identity, because your network now understands this privilege, you're now able to block this attack for even further by allowing them to try to attack the machine, but not actually being able to actually get packets into that machine, resulting in the machine is not compromised. Same sort of situation before, though, if the laptop that was compromised has an identity, which is permitted to communicate to that target laptop, then the same situation can happen where the attacker has successfully defeated all of your zero trust privileges and has gained access to a machine that will give them access to that target and compromise the target. So let's take a look now at how we can make this a bit better by using application embedded zero trust. So we're going to focus on our corporate network still, and that that corporate network is going to have our attacker and we're going to attack the same machine. In this case, what we're going to do is we're going to try to embed zero trust, not only in our network, but also into our applications themselves. So we're going to take one of our ZD SDKs, use it, compile it into your application itself and then create a secure application, which is then able to be delivered to all your users or anybody who wants it. So now we have these secure apps delivered out to users. We still have that strong identity, the strong network identity, except in this case, the identity is contained within the application itself. The application is now identity aware. So this is what that might look like. Here we have an example of an attacker that is on a machine that has been compromised. We have strong applications with identity embedded into them. And now we're going to have that attacker try to send traffic from the SCP application to the SCP application. And since the SCP application is identified and authorized, then obviously traffic is allowed to go to the SCP application. The same would be true for the SQL server application. And we're going to just ignore the fact that SCP and SSH are kind of the same app for now. But SSH is the same thing. If you had an SSH app that could only talk to SSH, then obviously that would be allowed to send traffic to the SSH application itself as well. So what would happen if the hacker tried to compromise the SCP application and send SSH traffic? Well, since the application itself is application is identity aware, it has the zero trust principles the ZD SDK provides. You don't have to worry about it because the SCP application literally cannot send traffic to the SSH application. The SQL server application can send traffic to SSH. Same is true for SCP, etc. And so that's where ZD comes in. OK, so now we've seen some of the reasons why you would want a zero trust principles added into your application itself. There are some other great superpowers of a application embedded network. Here's a picture of two cars. The car on the top is a car called the Beast. It is the limo that the president of the United States drives around in. On the bottom is same style of a car, but not quite as elegant. It's a it's a phrase that you'll hear some of the people who talk about ZD use, which is build security into your application. Don't bolt it on top of your application. Obviously, when you build it in, you have much better access to the code itself. Your code is entirely in your own process space, as opposed to relying on bolted on security stuff that you've not actually had the luxury of baking into your application. Obviously, one is more sleek or more more better defenses and one just is this, you know, haphazard keeps slapping armor on until we make it work sort of approach. So baking an open ZD SDK into your application, obviously, be much more like having your security baked into your car. So with the open ZD project, because it is a zero trust overlay network, one of the things that you're going to want to do is you're going to want to send messages from, say, your client to your server. Classically, this would be an example of how a developer would send messages to a server. You would use a domain name like my dot application dot server. Obviously, not a proper top level domain, but that's not important right now. And then that would be mapped to an IP address. And then when the other side receives the message, it would say, hey, 192.168.2.3 is the endpoint that sent this message, unless you're using a protocol that allows you to embed extra stuff around the top of it. With the open ZD SDKs and with the open ZD overlay network, you have this already for you out of the gate because they're that strong identity that we talked about before. Since there's a strong identity, now this Clint user can simply dial Jenkins and you can refer to it as Jenkins or however you choose to name it. It's just the name of your identity with a ZD overlay network. You don't have to rely on DNS. You can if you want, but you don't have to. And particularly with an application when you embed it in your application. Now you can just address who you want to send your traffic to. And the other side will know who you've actually sent the track, who has sent the traffic, and it will know perfectly because it will have that strong identity. And so it's not just for the classic client to server either. Oftentimes when you start thinking about Zura trust on your journey, you will focus at the edges. One of the things that is often overlooked is that you can absolutely consider the server side to be an edge, as well as the the actual end user side. Lots of people are moving to this direction segmenting their own internal networks. You know, DMZs are one thing, but also allowing people to only access the machines once they're inside of the network itself by micro segmentation that we saw earlier. So here, because it's a zero trust overlay network and it's bi-directional, you'll have the ability to add zero trust right to your server side, as well. You don't have to rely on deploying an agent in your local machine or in your local environment or deploying a router or something along those lines. You certainly can do that, but you don't have to. So this is a pretty cool feature of OpenZD SDK. And then since I actually kind of, I don't know if I said it before, but because it is an overlay network and because it is bi-directional, the server conduct directly to the client. You can stop thinking of them as thinking of them as actual servers. You can think of them as just any other endpoint on the network. And as such, if there is a device that is addressable, then your server can just be any old application on your network and just address the client that you want to address. Also, in the old days, in order to do something like this, or actually right now, you could do something like HTTP long polling. So you can do this, you could use WebSockets, you could use a server side. I can't remember SSI. You could use server side, whatever it's called. I don't remember the term off the top of my head, where you can send traffic from an HTTP server. But if you have something like SSH or a point-to-point, other point-to-point protocol that you can use, you can use SSI, SSI, SSI, SSI, SSI, SSI. that you wanted to involve, you can just address that endpoint using the CD identity. Another cool thing that CD does for you just for free is it is end-to-end encrypted. The device which is sending traffic will actually communicate to the far-end first, and that far-end and close-end will both negotiate some certificates and send some ephemeral certificates and encrypt your data correctly, and and does this all for free, you have to go out of your way to actually turn this off. Why that's really neat is because if you are using an insecure protocol such as HTTP or FTP or something along those lines, then you don't have to do anything in order to get into end-to-end encrypted traffic. You can simply use the overlay network. You get that strong identity. You get the zero trust overlay network and you can send your traffic being more secure that your traffic is actually safe and secure. Now, if you're using FTP in your application itself, you can be very secure because the SDK will be baked into your application. Your encryption will happen in your app itself and then it will send it to the other side where it can either offload from the ZD network or go right into that server side enabled protocol, whatever it is, our server. One more thing that's really cool about adding a SDK that enables zero trust into your application. One of the things that you can do with regular traffic is you can start looking at what ports are being consumed. So here are the top 20 ports. I just went out and found this blog and these are the top 20 to mention but obviously some of them are ones you're gonna see. 443, very common, Port 80, very common, FTP, SSH. All these are really common ports. So just by looking at what kind of traffic is traveling over the network, you can gain some information. What if everything was just HTTPS as opposed to actually knowing what port is being used? With zero trust overlay, you have that capability. So it basically hides your servers. So in fact, I didn't talk about the dark servers before because everything here is all through 443, there's no inference that can be gained. I did forget to mention before that when you embed a zero trust SDK into your server side, you no longer have ports that are open, no longer have ports that are attackable. I do have a slide about that in a second. So now, since all your ports are 443, totally obtuse to anybody who's scanning your network, it looks like it's all 443 traffic. It looks like it's all going to the same router endpoints. You don't have to worry about somebody making an inference about what kind of traffic that you're trying to send or where you're going. It's also very easy. So here you'll see the before example and the after example. In the before example, we're using Java. We are starting up a server and we're listening on port 8080. So I need to know what IP address I'm going to actually be binding to. Sometimes it's oftentimes it's not local host, right? It's not 127.0001. It's some actual IP address. So I need to know what that IP is going to be. I need to, or I can listen on all interfaces, which is what I probably would do normally. And I also have to know what port I'm going to be listening on. But with ZD, I don't have to worry about any of that. I can just tell ZD to start a server and to start listening. And as long as my identity has the permissions to actually listen for incoming traffic, then ZD will just take care of all that for you, which is really nice. I also don't have to know what IP address to listen on or what port. I just say what service I want to be bound. And now all of a sudden, that super secret or super secure service is addressable through the ZD network right into this machine. This is just an example of how it would look in Java. We do have numerous SDKs. So if you're interested, we can look at that in a second too. So at this point, I would imagine you're thinking with all this technology, so great and wonderful and you're wondering how you can package it up and go get it. I do have a slide here. It shows you where you can go get this stuff. It's all open source. We have a landing page called ZD.dev that has a bunch of information on it and it will take you as well to the openzd.github.io. We have some GitHub pages out there. You can see we have some quick starts and that's an old screen cap and we're gonna have to update that. All of our stuff sits on github.com slash openzd. So you can go out there right now and take a look at it and see what kind of commits are happening. We also do have the openzd incubator as well. And I'm gonna show you some of the things that are coming out of the openzd incubator as well. So when we add ZD into an SDK we refer to this as a Zedification. So we have actually Zedified some applications on our own. One of which that we have done and you can go read the blog post about it is ZSSH. Why bother with ZSSH, right? So it's the classic reason when you are accessing a machine through SSH you're going to need port 22 to be open and your machine will have to have port 22 listening. This is how the internet works. It's usually secure, but if you have a machine out there that has port 22 open, like say a bastion, you can guarantee that that machine is getting attacked all day long by port scans and password attempts, port cipher attacks, et cetera. With a zero trust SSH you don't have to worry about any of that because now you have no listening port when you fire a wall. Your remote SSH machine attaches to one of the overlay networks and nobody knows that your SSH service resides behind that actual machine. Same structure for SCP. So SCP runs on SSH. And so we have here an example of how you could just do an SSH on the top and an SCP on the bottom. I do see a question, can ZD enforcement be transparently added to traffic between clients and services that aren't aware of ZD? That's a hard question. It's actually interesting. So I might talk about that one later or Phillip can answer it in the comments, but basically that's probably gonna come down to running a tunneling type app and working more like a VPN. But maybe we can explore that afterwards because I think that's going to be a difficult question to answer quickly. Mattermost, so Mattermost is our chat app. Phillip actually is typing an answer. He works here at Net Foundry. We have a zero trust chat app. We don't use Slack anymore because it's not zero trust. So we have Zdified Mattermost. On top of that, you'll see that when I am in Mattermost like I show here, I'm getting messages from GitHub. How can I get messages from GitHub when I have a zero trust chat client? Well, we have web hooks that we wrote that allows GitHub and GitLab. So when I push a commit to code, it basically notifies me that a commit has happened. And in order to do that, the commit hook or the post commit hook has to be behind or has to be able to obtain access to the ZD overlay network. So we have web hooks for GitHub and GitLab. We also have created a generic JDBC wrapper that uses JDBC or sorry, ZDBC. Here's an example of what that might look like. So here I have data grip. And what this is is it's basically a driver that wraps around your JDBC driver itself. This is cool because now you can take your Zdified application. And if the target like this case data grip supports a plugin, you can author a plugin that adds zero trust to something else without actually having to own say data grip itself. This is a really neat kind of Zdification where if you have this access to plugins, you can do this sort of stuff. And here, you can see on the top, number one, I've called it ZD Oracle. I have a data source and the driver is the Oracle with ZD driver. So there's some configuration I had to do, which you could learn about, but I've configured the driver to use ZD. And then I've told ZD that it's a ZDBC as opposed to a JDBC URL. This kicks off ZD. All of a sudden now my traffic is being sent over the ZD overlay. Oh, another fantastic point I didn't mention, but when I'm on the overlay network, it literally does not matter where the target is deployed. So it takes everything out of the equation as far as topology goes. As long as you're a participant on the overlay network, it does not matter where your endpoints are hosted, which is I think really neat because now you have the ability to do something like, I was talking to a developer of mine that was working on Postgres, actually working on this, and I connected to his actual database. So Todd was the fellow who developed the JDBC URL. He was running Postgres inside of Docker and it was not exposed at all. So we had fired up a Docker environment and deployed Postgres on it, deployed ZD in that Docker environment, which you could equate with Kubernetes or whatever other kind of server and structure you wanted to use. And I was able to access his Postgres database from my computer here in my bedroom office, which I think is really neat. There's also kubectl or kubesetl as we end up calling it. So basically when you look at an overlay network, you have two ways of implementing that network. You can either use say unmodified kubectl, talk through a tunneler, which we call these things tunnelers, across the ZD overlay network into the pod that's deployed into the Kubernetes world and then talk to the Kubernetes API itself. Or you can just use a Zedified kubectl command where we've actually taken ZD, added it into the actual kubectl command and thus made kubectl application aware, zero trust. Now I no longer need this desktop edge for Windows, which I have running on my local machine right here. You can see mine. I don't need that VPN client anymore. I just need my application itself deployed with that strong identity, or it can enroll itself and make its own strong identity, which is probably a better idea, but you get the point. And now I don't have to worry about having my identity actually on or my tunneler on. I can just use the Zedified version of kubectl and now I can access the kubectl Kubernetes environment live. And I can do that in a second too if we wanna see a demo at the end. This slide here is the longest path that you can travel by walking across the globe. So if you apparently start in South Africa, you can walk all the way to that point in Russia and it's the longest path. And the reason why I like this slide is because it represents the fact that zero trust itself is a journey going right from having, you know, that castle wall and moat sort of idea directly to application embedded zero trust is without a doubt going to take some time. You're probably not going to start off going full application embedded zero trust, you know, from the start. So instead we have these tunneling apps I've already shown you one. This is where people probably end up starting out where you can deploy these basically VPN like clients, learn what a zero trust overlay network is, understand what it does for you and then be able to, you know, progress on into application embedded stuff later on. Same idea here. You know, we have the, you can have a ZD desktop edge for Mac talking to a ZD desktop edge for Windows or Linux I should have updated this slide. What a mistake. Boy, that's a fumble. Let's say Kubernetes though, Kubernetes is deployed in Linux that counts. And this here is a platform nine example. You know, it doesn't matter, it doesn't matter what cloud you're deploying into. That's the part of the beautiful part of ZD. Doesn't matter what cloud you deploy into totally cross cloud or no cloud, right? Private cloud only. If you wanted to run your own data center entirely, you know, you have VMware cluster of your own ESX or whatever it's referred to nowadays, then you could deploy ZD right in there and have private access directly into your data center by only the people that you authorize. This is not just a passing fad. The reason why I include this slide is because the president of the United States has actually mentioned Zero Trust. And if you search this slide or search that page, you'll see that it's actually mentioned 11 full times. So it's not just some sort of fad. This is, I truly believe probably where the future is going to go. I believe heavily that Zero Trust for corporate environments is where you want it to be and also not just for corporate environments, but for any project that you really want to be safe and secure. One of the examples I haven't produced yet, but I plan on doing is home IP camera, right? Like anything IoT related that you were doing at home, your garage door, your Plex server, all that sort of stuff. If you want to have secure Zero Trust networking, you know, ZD's where it's at, my opinion anyway. They also have this really nice maturity model they've published on this page here. You can go out and read all about that, which is really detailed. You can see they cover a couple of things that we've talked about, the device itself, identity, data, and flight and rest and those sorts of things. You can actually go get ZD right now. Here is the landing page that we'll get to, that you will get to if you go to, it's awfully small. It says openzd.github.io. I include it in the last slides prior in the next slide too. But here you'll be able to go out there and get your own version of ZD. We have everything local without Docker kind of example. So if you are like me and you don't necessarily want to run Docker, but you have a Linux machine and you have Bash or ZSH, I think those are the two I tested with. Then you can go out and you can fire up your own Zero Trust network entirely local and do that with a one line script. In fact, I'm gonna show you how to do that in two seconds. And then we have someone with Docker. So if you're, you know, if you like Docker and you want to use Docker, you know, maybe Podman or whatever, I haven't tried it with Podman, but if you want to use a container engine locally, you can do that. I have tested it and documented it for Docker. You can also host it wherever you want. Like I have deployed a hosted environment out in Amazon for use. We obviously will focus on the SDKs themselves. And those are the ones that we have right now. And some of them make sense for servers, some of them don't. So I'm gonna go over to today. I have the Kotlin logo instead of the Android logo on that. So I'm gonna have to fix that too. So look for that pull request. And that's basically the overview of Zero Trust app embedded security. And these are some of the socials. You know, we're on Twitter at OpenZD. We don't have a hundred subscribers yet to OpenZD. So unfortunately, it's this big, ugly URL. But if you search YouTube for that OpenZD owner, you'll find us. So if you sub and get us to a hundred then I can get an actual reasonable YouTube channel name. It's my goal anyway. So let's take a look real quick. I see we have time. We have a couple of questions. So how are vulnerabilities managed? That's a good question. I see Philip typing, but I'm gonna talk about it too. Right now, we don't have a responsible disclosure form. We are working on that because that is obviously a really important piece of the puzzle. Our head of security is actually doing that as we speak. It's something that we've been reviewing, but basically we'll have an email address for you to, you know, hopefully responsibly disclose the vulnerability and we'll take care of it as soon as possible. Right now, we also have a disc, obviously we shouldn't do it on discourse. We do have a discourse site. You could go through and say, hey, I have one, you know, let's get in touch. That goes directly into my matter most and I'll get notified immediately about this as well as the entire advanced development team who works on OpenZD. So if you were to post something there, I would guarantee that it would get some attention. How does the tunnel feature compare to tail scale? That's a good question. I actually was ready for this one because tail scale is built on WireGuard and WireGuard is not like ZD. WireGuard is a point-to-point protocol that is very secure and very popular and TailScale takes WireGuard to the next level by making it easy to deploy a WireGuard network. I would say they are very similar in a lot of ways. TailScale is not purporting to be a zero-trust overlay network, not so much as a secure VPN. At least the last time I checked, I didn't see any zero-trust mentioned on their website but they do take WireGuard and make deploying a WireGuard overlay pretty easy. So Philip might have better information on that. I know he does some of the competitive analysis more than I do. But yeah, that's my presentation. So I do have a couple of demos real quick to show you. I have my... While you're doing, I'm actually, I'm not an expert on WireGuard and TailScale but I was having a custom conversation this week where they built a like a POV for what they wanted to build using WireGuard and then they came across CT and they said, we're going to use this for production because it does all of the zero-trust and all of the security stuff that we want that WireGuard doesn't do. Yeah, I mean, yeah, for sure. And then I see a new question. What about services that are not ZD aware or zero-trust aware? Are there proxy components that can be deployed in front of services? Yes, that's these tunneling applications. So when these... I didn't get into it, but I can because these tunnel... The overlay network in app embedded is my target here. Like that's where I really think the future is. The tunneler is part of the journey to get to application embedded but it's not, in my opinion, the end goal because you do have to have one of these agents in front or a proxy like was mentioned. Good question. Yes and no, we've had a little bit of problems with the tunnel sidecars, but yes. There's actually a... If you go and Google net foundry sidecar, you should find that out there. In fact, I think, let me bring this up real quick. If I go to my docs and go to Quick Starts and go to Kubernetes sidecar tunneler, you can see you can deploy a tunneler. This is old. So if you go there and try this, like just hit me up in discourse because I don't know if it's to work. Part of the redoing the doc is part of what I'm working on. But it might work, let's see. But yes, we've actually done this and deployed this and this is a simple example, but it gets more difficult when you try to have other pods in the Kubernetes cluster use the same... Or use a nucleus pod, like I think it's called a daemon set or something along those lines. I'm not a pro when it comes to Kubernetes, but I do know that that is out there and we do do this. The tunneler, I wanted to talk about the tunneler app because I didn't cover it here, but one of, I think the coolest things about ZD is it allows you to just invent your own DNS name. So if you wanted to go to mattermost.tools, you know, I want to do it in curl, in case there's something crazy in my window. Let's do curl. If I were to curl to that URL, you'll see I get HTTP example back, right? Like this actually did something and went somewhere. If I then come back over to here and I turn off this tunnel, and it takes, if I do that curl again, you'll see it says forbidden, which I don't know why we say forbidden. That's actually new, that's a new development. I think it's cached, I don't quite know why that's giving it a forbidden. Probably return some sort of error code. Actually, maybe I'll give it a dash B. Let's see, 403. I don't know how that made it through. I'm gonna have to look into that because I don't like that. But you can see it didn't work, which is interesting, I'm gonna check that out. Here's the quick example. Let me go through this real fast. This is the one liner install. This GitHub has a really nice URL shortener. I learned about a couple of days ago. So this makes it really easy to do. If you've already run it once, which I did like an hour and a half ago because I just saw these presentations to my internal team just a minute ago. It'll go through, it'll do all kinds of stuff like create this whole PKI for you, which is all gonna be self-signed. So if you really wanna learn about ZD, you'll have to dig into that at some point. But now you can start up your controller. You can start up your edge router and then presuming everything works. I can go to ULU1280, which is the URL of the ZD controller and get a version, which is the same thing as that, I think. Yeah, so there we go. So that worked, that's great. Now I can stop. Oh, by sourcing that script, you can see that it added a couple of functions to your bash prompt here. I use Windows, which probably everybody could tell down here, but this is obviously gonna work in Linux and obviously in Mac too, we test it in both of those. So if you're using one of the better operating systems, then you'll be able to run that sort of stuff. We have the quick demo on, let's see, network starting with Docker, come on, with Docker. We use Docker networks, which is nice because then you can create a bunch of ZD networks if you want and segregate them on your own. I'm not too much there. We can start up our controller here. When we come over here, we can start up our router. If you exec into the container itself, Docker, exec, IT, I don't know which one it is. Let's see if it's this one in bash. Let's see, and then we do a Z log in. There's a function that will let you log in. You can then do a ZD edge list edge routers and see that we have one edge router online. That's fantastic. So I just started up that environment using Docker. We have a Docker compose example, which is a bit easier if you have Docker compose installed. It also creates a much more complicated network, one which has a trivial web server built into the balloon network, which is only accessible through ZD because it is not exposed on... Actually, if you look in the compose file, it's probably exposed on one port that you could get to at it, but regular URL, you can't get to that. So if you curl to 8000, if you turn on ZD, you can now curl to port 80 and get there. So that's a good example that you could try for yourself as well. And then if you wanted to host it yourself on some machine, like I have hosted one here out on EC2 I talked about. So here's my, well, that's a good demo. Oh, it's HTTP, yes. Hey, that's better. Saved it. All right, so let me bring this over here. So I can't bring it over here because it's not sharing. There's my version. We also have this thing called Zac, not version. If you go out here and follow along in the ZD administration console install, you should be able to get a UI for all of this stuff too, which is great because now you don't have to use the ZD CLI, but if you wanted to script it and use the ZD CLI, you absolutely can. If you want to use the Zac, you can. All this is open source all up on GitHub. We have that, we do have that discourse URL. So if you want to talk to me or anybody else in the team, you can talk to me in the team, hit us up on the socials. And I think that's the end of the whole presentation. Thanks for the questions. Those are good questions. Wonderful. Thank you so much for your time today, Clint. And thanks for jumping in on some questions, Philip. As a reminder, this will be available on the Linux Foundation YouTube page later today. And we hope to see you all at another webinar. Thanks, everyone. One quick one. We got a question, can ZD deploy the cloud? Absolutely. It doesn't matter where you deploy ZD, for sure. Private cloud, public cloud, whatever. Wonderful. I'm glad that we got that one answered. All right, everyone, have a great day. Thank you. Bye, Megan. Bye.