 You ready? All right. Well, hello, everybody. Thanks for coming to my talk about application embedded zero trust. My name is Clint. I work for a company called Net Foundry. We sponsor and support an open source project. You can go out and get up and find it right now. It's called OpenZD. It's all about taking zero trust and embed it in your application. As you may have noticed, you're not anybody until you have a mascot. And we have a mascot. And this little guy in the lower right hand corner is Ziggy. So you'll see him throughout the presentation. You can find him on Twitter. And you can find him under our branding stuff out on GitHub. So what we're going to do, we're going to talk about what is zero trust. We're going to talk about what the current state of network security basically is. We're going to talk about what application embedded superpowers are and what those look like. And then we'll see some applications that we've actually added zero trust into to make a thing that we call a Zedification, a Zedified version of that application. So let's talk about the current state of network security. We have a basic network here. It's probably like one that you all have. We have a home office in the lower left hand corner there. We've got cars, which are maybe connected through some sort of cellular tower. They're IoT devices, maybe. We have a home network like the one I use at home. I've got my cell phone that attaches when I go home, regular laptops, all that sort of stuff. Basic overview of a network. Everybody's seen this. Everybody should be familiar with this. So what are we talking about with basic security? We're talking about this thing that's called the wall and moat mentality, where every single little fiefdom is its own castle, has its own little drawbridge. In this case, we're representing it with a firewall, has a moat, and you need to get over that moat, and you need to get through that drawbridge. If you can get over the moat, if you can get over the drawbridge, or through the drawbridge, or through the walls, then you're considered trustworthy, and you're able to send traffic amongst wherever you want to send that traffic to. I need to expand my slide to send it elsewhere, but we're looking in the lower left-hand corner here. We'll allow that traffic just to flow in. And this is what it was like around 10 years ago, right? Not even that long ago, where people would have a network that was just, once you were on the corporate network, you were totally secure, you were trustworthy. So lots of hackers would come in, they would get their Wi-Fi devices, they would attach to the Wi-Fi network, they would attach their ethernet cable and just plug into the jack and have access to every server, every computer that's in that network. So people said, that's probably a bad idea. Let's do something better. Let's start using secure protocols. So TLS said, hey, we're gonna use TLS everywhere. No more FTP, we're gonna go with SFTP or SCP. We're not gonna use telnet anymore, we're gonna use SSH. And so we decided to use telnet everywhere, or telnet everywhere, TLS everywhere. Using telnet everywhere is not a good idea. So, let us do a little bit of a challenge for most people, because now you need to have some sort of cryptography, you need to have some sort of protocol that actually knows how to encrypt traffic. Thankfully, TLS doesn't make that kind of easy. So you can negotiate your packets and go that way and it works out pretty well. So that's what we did forever. There were a couple of companies that said, hey, that's not good enough to do that on your local environment. I need to make this easy for everybody. So there was this plug-in way back in the day, you don't find it anywhere because it's in every modern browser now called HTTPS everywhere. Basically, what it would do is say, hey, I'm going to HTTP dot, or colon slash slash Google dot com. And HTTPS everywhere, we go, whoa, whoa, whoa. Google has an HTTPS endpoint. Let me just redirect you over to the actual secure one. And poof, off you went, never knowing any different. The browser said, hey, that's a really good idea. We're gonna take that idea and we're gonna just subsume that whole plug-in into all the major browsers. So now when you go to a major browser, you'll have this happen, you'll type HTTP in, if you're a developer, trying to get to port 80 because sometimes you do do that, it's a right pain in the butt. But it happens, right? So that's cool. And then Let's Encrypt came around and said, hey, all this TLS everywhere is a really great idea. Self-signed certificates though, kind of a bummer. So why don't we make this thing called a certificate authority? We will be, well, they tried for a long time to get themselves added to actually every operating system that's out there. For a long time you had to import Let's Encrypt into your environment, but now you don't. Now Let's Encrypt comes for free with every single operating system that you have out there that's available, that's modern, last like three or four years. So you can go out and get yourself a certificate for Let's Encrypt and you can pretend, not portend, not pretend, to be who you say you are and Let's Encrypt will say yes, this person's that, or this device is that device that you're trying to connect to. So it was really great. So great, like I said, that HTTPS everywhere now is just ubiquitous. Okay, so let's come back to our network where we have our little walls that are moats and we have an attacker who has gotten into our secure area. What are they gonna do? Well, they do what attackers do, they send malicious packets and they find some sort of zero day and they exploit it. All right, well, that's not a good idea. Security, so that's, we gotta fix this. What are we gonna do? Well, let's first of all, I missed my slide off, I should have lured. So in case you haven't noticed this is how VPNs work, right? So VPNs are actually gigantic castles and moats. Once you're attached to the VPN, you are almost always ubiquitously connected to anything else that is attached to that VPN, at least in the VPN 1.0 kind of world. Things are changing here a lot. You might hear of a product or project called WireGuard. WireGuard does a really nice job of trying to make a slightly better VPN. Lots of products are now built on top of WireGuard. You'll find tail scale and other things, right? So that's what a VPN does. Here we go, now we have our little Ziggy the cop. He's in here and he's going to be performing a very important job. He's gonna be segmenting our network. So in the lower left-hand corner, well, we used to have one big castle. Now we have two little castles and network engineers rejoiced and they said, hey, that's great, Ziggy's gonna stop all of our traffic. Problem is solved. But of course, that's not gonna be the problem. What's gonna happen is there'll be one of those devices, the middle one down here, which necessarily needs to be able to access both the developer network and the QA network. It's the QA device. So our malicious hacker goes out, compromises that laptop somehow, and now they've gained access to that target machine that was on the far right. And so this is basically what happens nowadays. This is called land and expand or horizontal movement. So this is where zero trust starts to come into the picture. All right, here we go back at our basic network and we're gonna stop using the wall, the castles and the wall mentality. We're gonna just focus on this little diagram for a moment. And now let's enter the first pillar of zero trust. I can't talk about all of them, but there are two really, really important ones. The first one is device identity. So let's take the same basic idea of the wall mode, but we're gonna keep it with the firewall idea. And what if every single device on your network had a strong identity? And what if that network was able to understand that the device's identity was or was not able to even communicate to other devices on that network? It's very smart. The only problem, the only challenge with pushing device identities everywhere is that you have to do something called bootstrap the trust. How do you trust all of those devices? How do you actually get some sort of strong cryptographic identity on each of your endpoints? So this is the process that the project that we're gonna talk about later to implement. This is how we actually implement our enrollment process. So if you wanna talk about this, we can, but I'm gonna just gloss over for now. Just you look at it and you go, that's a lot, right? So just know bootstrap and trust is hard. Okay, so now we have an attacker. They have plugged in their ethernet cable and they're gonna try to send payload to the network. And voila, they can't, right? So the network has been smart enough to say, hey, you are not even permitted to send packets on this network. But attackers are nefarious and they're also determined. So they're gonna go find somebody who can actually talk on this network and then what happens, we all know what's gonna happen. They're gonna compromise that target laptop again. Those guys, I tell ya. All right, so that's where least privilege comes in. So now least privilege is all about understanding what devices can talk to what other devices or what identities can talk to what other identity. So here we are, that same person comes downstairs. He's like, I've got this laptop. I'm gonna attack that target. But this network understands that the identity which he has compromised is not capable of talking to the device that he's trying to talk to. So he's all bummed out, right? Gives up, goes home. We all know that's not what's gonna happen, is it? They're gonna find a real device that actually has access to the network and they're gonna compromise them instead. But remember, security's all about layers, right? We've already, we've made this so much more difficult for our attacker. They've had to compromise not only a machine that has an identity but a machine that has the correct identity to be able to talk to the, or target the target that it's trying to get to, to send packets there. Okay, this is where application embedded zero trust comes in. Before I get into application embedded zero trust, we're gonna talk about an overlay network. Because previously I was showing you layer three kind of underlay, as you'll see me or hear me listen or refer to it, the actual things that almost everybody's familiar with. IP addresses, MAC addresses, right, the OSI model. An overlay is a little bit different. An overlay builds a network kind of on top of the underlay. So here we are with the internet. We're gonna call it the overlay, just like that. Right, now we have an overlay. What goes into an overlay? We have a controller. The control plane is responsible for making decisions like what devices allowed to talk to other devices, et cetera. We have a bunch of these things we call edge routers or just regular routers. And what those guys do is they form a mesh. So you can deploy many of these things out there. And have a diverse and also very fast path between system A and system B. And then we need TLS everywhere because we're gonna have secure. And this is mutual TLS, so you can see all those lock signs. It makes the diagram very messy. So on the next one, we're gonna take care of all those little lock signs and we're gonna just simplify a little bit. And now we have ZD baked into your computer on the left and ZD baked into your servers on the right. And what's that for? Well, that's just to send packets over this overlay network. So this is basically what an overlay is. We're not talking about IP addresses anymore. We're talking about an identity to an identity communication. So you saw me reference before those little disks, little routers, we have little Zs for the host access and little Zs for the application. So let's talk a little bit about that. Generally speaking, when you talk about zero trust network access, you think something like this, right? I have my secure area like my little house. I have the corporate office and anything that is able to get on to the overlay network is able to offload on the other side. Now with zero trust network, you have to authorize everything. So that's not particularly accurate, but this is kind of the idea. The trust zone here, however, is everything outside the gray zone. So if you were able to get onto the router, then you're able to actually inspect where this packet is going, what that packet is doing. If you're not able to get on the router, if you're able to get on the host, you're still able to do the same thing. So next we'll have zero trust host access or ZED host access. Here, you have a little agent that runs on your local computer. WireGuard has an agent like this. OpenZD has an agent like this. Lots of products, projects have a little agent like this. And so this is even better because now your trust zone has been reduced dramatically. You only trust the host that you're on itself and the host network that you're on itself. You don't have to trust the actual, you don't have to traverse the actual network. But there's one step better and that's bringing it all the way into your application. You'll see I have not called the server host and the device host totally untrusted. You will never get away from having some amount of trust. You have to have that somewhere. So I participated in a Reddit post one time, got flamed up the Wazoo for using the term zero trust because I was talking about how you can, you don't have to trust anything but you can make your own trust, right? And people didn't like that. So zero trust is an overloaded buzzword. I've used it here because it's accurate. It describes the paradigm, but effectively you will have to trust the device because if you can compromise the device and you have sufficient know-how, well then the game is off. But if you don't have sufficient know-how or if you haven't compromised the device, you're just able to attack some other application on your machine. Application access like this is amazing because you're basically impregnable to side-channel attacks. All right, so application embedded zero trust, we're gonna take a look at our attacker and our target device. We're gonna focus on this for a little bit. So what we wanna do is we wanna take an SDK. We have a bunch of SDKs go, see C sharp, Python, et cetera. And we wanna stuff it into our application or compile it. And then we're gonna deliver that application to our evil compromised machine. So now there are attackers, they know how to use networking tools, but they don't exactly know how to compromise an open ZD network. So let's say they're gonna try to send SCP data to the SCP server, great, that works. They're gonna send SQL to SQL, great. FTP to FTP, everything's great. The yellow traffic is supposed to go to the yellow endpoint, the green, the purple, the purple. But if they try to use SCP to attach to say the FTP server, they can't do that because the application itself, if it's been Zedified, if it's had an open source zero trust SDK baked into it, only knows how to communicate to the other applications which is allowed to communicate to. Same goes for SQL. You try to send FTP traffic from SQL, obviously it's made up, but if you did, you can't. And you can't send FTP, sorry, SCP traffic from SQL either. And so now we're gonna talk about open ZD, which is the open source project that I work on. And we're gonna see some superpowers of embedding zero trust into your network or into your application, sorry. So this is the first superpower. I don't know if anybody's familiar with the top diagram, but that top car there is the limousine that the United States president drives in. The bottom picture is something that's more relevant to a Mad Max style of security. So on the top, you have sleek security, right? You have bulletproof doors, you have bulletproof glass, you got blastproof tires, like this thing is just chock full of security, but you'd never know it, just looking at it, would you? The bottom one, you can see where all the security is. You know where the weak points are, you know what the target, you know how to get through the chinks in the armor. So having your security baked into your application is one more layer of obscurity. We've heard the term security through obscurity a million times. So this is just one more layer of that. Addressability, with an open ZD network, you actually know the identity of the individual or of the application that's communicating to your endpoint. So in the old days, you would have an IP address, that's the underlay, and then you would send it to some DNS name, that DNS name would be actually translated into an IP address, and then your underlay would shuffle your data from one place to another. In the new world, with open ZD, you're able to say, hey, I'm Clint, I'd like to talk to Prometheus, or Jenkins, or Mail server, or your application server, whatever it may be. Really powerful, you know exactly who's coming in before they're actually able to connect to your application. Because it is server-side, there are no listening ports. This is without a, oh. There are no listening ports. So what's really cool about this is with ZD, you have a deny by default firewall policy. Everything is, you initiate outbound connections, so you need an outbound firewall rule that lets you attach to the edge router, and that is it. Once you are attached to an edge router, ZD takes care of the rest. So there are no listening ports on a application that is listening. Now this might be relevant to some of the Java developers who are out there, right? So if you have a hole in your firewall, and you have a really nice Spring Boot app or a log4j app in there, well then these bad people would go out there and they would exploit that. They would do something called log4shell, or what was the other one? Spring for boot? Spring boot, no, Spring4shell, I think. Yeah, and in fact, yeah. So now with OpenZD, with no hole in the firewall, that nefarious attacker is no longer able to access the service and affect your endpoint. Now, those who are astute among you will notice that the three blues machines can still communicate to your target. But again, it's all about reducing how many people are able to access your machine. The number one wave that exploits happen nowadays is through scan and attack, right? So they just go out there and scan for whatever might be out there. If they can't find it, they probably can't attack it. And that's where Spring4shell comes in, which was rated at a 9.8. If you haven't looked into this, that's a really fun one, a CVEs. I don't know if you're familiar, but CVEs are great to go out and consume. There's a guy, OpenZiggy, if you're on Twitter, he'll tweet about 9.8. Usually he'll tweet about CVSS scores, another cool thing. If you haven't looked up CVSS, I recommend learning about CVSS. It's a way of scoring how vulnerable something is. So that's a 9.8. And OpenZiggy will look for attack vector of network with permission required of none. Those are very dangerous because it means anybody, anywhere can exploit that thing. It's also bi-directional. So generally speaking, when you think about communicating to the server, you think about long polling. So I come from an IoT background, right? So you think about WebSockets. You think about HTTP long polling. You think about maybe GRPC, I guess. But with OpenZiggy Network, you can just communicate from one identity to the next identity. So it does not, the whole notion of server and client becomes a bit nebulous. Everything is addressable on the network if it's permitted to be addressable. So I'll bake around this thing called Libsodium. The Libsodium is a library that provides encryption. So you get end-to-end encryption for free when you use an OpenZiggy overlay network that's got this cha-cha-poly or a cha-cha-20-poly-1305, which is the actual algorithm that's used in Cypher. Very lightweight, good for low-powered devices, which is one of the reasons why everybody basically uses it. Another great superpower is port inference. You're not permitted to infer what ports that you are looking at. If you go out there and you just scan a network, you'll see all kinds of crazy traffic on there. You'll see MySQL, you'll see SSH, you'll see TLS, you'll see all this kind of stuff, just by attaching a port scanner and just looking at what's going on. But with ZD, you're not gonna be able to do that because everything will look like it's going through port 443 or whatever port you choose, but port 443 is probably pretty common. So what happens is ZD will take all your traffic, synthesize it through a single connection, as shown, and it will just all look like 443. Doesn't matter if it's FTP, doesn't matter if it's SQL, doesn't matter if it's SSH. It's really easy too, obviously, right? So before ZD, this is a, I don't know if it's big enough, I tried to make it big enough for those in the back, I knew I was in the too deep room. So before ZD, this is a Java version. You have on the top, you have the idea of understanding the local host, which is the IP address that you're going to be listening on, could be 0.0.0.0, that's whatever lazy developer does, right? Am I right? That's fine. Sometimes you need to because the network engineer, he's out there and he's like, you know, I'm gonna be smart about this. I'm actually going to translate that IP address to what you think is the internal IP, is not what it's gonna be bound to, so you need to do 0.0.0. Anyway, you also need to know the port. I've also been really astonished when I deployed some of my own software and realized that the developer, the network engineer, decided to port, to change port 443 to port 8443, so helpfully, so I didn't realize why our application was having no traffic. So let me blow that up for you, because I knew I was gonna have the double room. This is basically what it looks like. Before you need to do the IP address, you need to know the port, when you're on a ZD network and you want to bind a service, this identity needs to have the ability to bind the service, first of all. And if it does, then you just say, I want to bind whatever that service is. Okay, so here's what we're gonna talk about some of the existing things that we've already done. Out on GitHub, we have this thing called the OpenZD Test Kitchen. This is where we try out interesting new things or we make our Z-difications. One of the Z-difications that we have started with is ZSSH. Teleport, I saw, top of Hacker News today. I don't know if everybody's talked to Teleport guys out there, they're out there. They have come up with a SSH for Teleport today, at least it's on Hacker News today. And why would people do that? Well, it's the same reason, right? Port22 is exposed to the world. In fact, I should actually add the blog post. We have a nice blog post about why Net Foundry stopped having Port22 exposed to the world. So we have a Bastion, everybody probably deploys a Bastion if they're smart, right? Like they have a Bastion to get critical resources. We have a dark Bastion blog post, which is pretty cool, shows you how you can take your Port22 and take it off the internet and then use it as a ZD overlay network to access your Bastion. Doesn't change a thing for the end user for me. I have to run an agent locally, but that's about it. And I have to be authorized, of course. That's why it's that bad. So it's good because firewall rule, no inbound deny all. That's what we want. We want no inbound ports on any device anywhere. All right, ZSCP, it's basically SSH. Just does file transfer instead. And here's a little example if you're interested. The neat thing about the sample is Magic DNS, is the thing Teleport did. I read the Hierarcher news article before. That's why it's off top of mind. They have a neat thing called Magic DNS, which lets you do this similar sort of thing. On the top, you hopefully can see it says ZSH to a place. And it's very verbose because I wanted to explain it. But it's telling you what identity file to use. It's telling you what service you want to use. And it's telling you what identity you want to SSH to. So Ubuntu is the user. ZSH server is not a host name. It is an identity name. So you can call that Clits SSH server. You don't have to worry about what it's called. As the developer, you get to decide what the name of that thing is and how to SSH there. And then you can do the same thing on the bottom with SSH or with SCP. You can just transfer some files. So that's cool. We have Mattermost ZDefined. We have a chat. Oh, it's actually, do we have them? Oh, we'll see it in the webhooks section. I knew I had it. So basically, with chat app, Philip here also works for the company. I work for Net Foundry. And so what I want to use are Slack clone called Mattermost, also out there. If you haven't stopped by the booth, check out Mattermost. But when we want to do that, we must be on our overlay network. Otherwise, we're not capable of communicating with one another. So I need to be on the VPN 2.0, if we'll call it. Why is that neat? That's also neat when it comes to GitHub and GitLab and webhooks. So if you're doing anything out in GitHub or out in the public space, if you have a zero trust overlay network, well, how are you going to have GitHub notify you in your chat app that somebody pushed a commit? I mean, I don't know about you guys, but I like to see most of the commits. I definitely like to see most of the pull requests. So we have a Zedification out there that takes the GitHub webhook and Zedified it also for GitLab. So if you use one of those two things, you too could have secure zero trust overlay network messaging and it looks like this. So I just get a message that says, you know, GitHub sent me some stuff. Generified JDBC wrapper. This one's really neat. So there are certain kinds of Zedifications. Usually, you think about baking an SDK into your application. JDBC is different. JDBC and Java allow you to do dynamic stuff at runtime. Go, for example, not so much. So what you can do is if you know how to poke and prod the legitimate JDBC wrapper, you can actually tell that JDBC wrapper to go someplace else instead. And you can have secure database access through your application or more likely through your database tool. So the database tool that I've shown here is called DataGrip from JetBrains and IntelliJ, whatever they are. And you can see I'm going to make this bigger because, again, big room. So what we have is, hopefully, you can see a ZD Oracle, number one over there. The driver is called Oracle with ZD on it. And then there's a big, ugly JDBC URL, but it works, right? So basically, you have to specify the address, not the address, the identity name that you want to use. And it's not just for Oracle either. So the cool thing about this Zedification is it's third party. And you can bootstrap it into your database app. Like, here's DataGrip. We did it with Squirrel, too, which is an open source one, which you probably should have taken a screenshot of that. But it's also for Postgres, right? So it does not matter what that driver is. You just have to poke the driver in quite the right way that makes it understand how to actually do a zero trust connection. One of the ones that didn't have time to make a slide for, this came out not too long ago. This is how we used Zedification for Spring Boot, which is really neat. So if you have a Spring Boot app out there, you can go and read this. It's not a sponsored article from Oracle. That was another one of the great comments we got on Reddit. We just posted it for them. But it's neat, because if you have a Spring Boot app, you can just have it be a dark Spring Boot app with two lines of code. It's really not a lot. CubeZedal. So those of us among us who have used Kubernetes, if you have your Kubernetes API exposed to the internet, like lots of people do, because you kind of have to. Well, you might be interested in CubeZedal. With CubeZedal, you can take your Kubernetes API, take it entirely off the internet. Oracle lets you do this. I don't know if the other ones, EKS, AKS do. But I know Oracle does. They have a SSH bastion, which is pretty cool. You can take your Kubernetes API off the internet through their bastion. It's very, very similar to that idea. So basically in the upper right-hand corner, we have a Helm chart that you can install ZD with. And then you will basically have a zero-trust ingress controller that's not a Kubernetes ingress controller yet. Open source project, we're going to get there. So if you want to contribute that, great. But what it does is it connects you to that zero-trust overlay network. And then from my local computer on the left-hand side, you can see I got a little picture of what we call the ZD desktop edge for Windows. That's the little tunneler. I can choose to get on the ZD network using that tunneler. I can use CubeZedal to get on our cube cuddle, I guess is the right way to pronounce it, right? Everybody, I don't know. CubeZedal, CubeCuddle, what do you think? CubeCuddle? CubeZedal? No, yeah. All right, cool. CubeZedal is the Zedified Cube CTL, because my favorite joke I make is if there's an S or a C sound and we can put a Z there, we will put a Z there. So CubeZedal is the Zedified version of CubeZedal. And that gets you on the overlay network without needing the ZD desktop edge for Windows, which is really cool. All right. HelmZ, same sort of idea. If you're going to have a dark Kubernetes, you're going to need to be able to access that dark Kubernetes. How are you going to do that? You're going to need a Z-defined Helm. Prometheus, we did Prometheus relatively recently. We took the Go SDK and stuffed it into Prometheus. And that was pretty cool, because if you're familiar with Prometheus in the upper left-hand corner, that's a basic deployment for Kubernetes. You'll have Prometheus Server outside of the Kubernetes world. And you'll have to expose both the Kubernetes API and Kubernetes through an Ingress controller. Sorry, and Prometheus through some sort of Ingress controller. But with an OpenZD world, you don't have to do any of that. You can install HelmChart. You can also choose to use the Zedified version of the actual program itself. So on the right-hand side here, you can see that there's no ZD host on the top left. There's a ZD pod. You don't need to do that. That's pretty neat. Recently, we've been doing stuff with Ansible and Python. So having a Zero Trust configuration management is pretty neat. We did this on a ZDTV, I think it was a week ago. ZDTV happens every Friday. It's a little live stream that I do where we talk about Zero Trust and Open Source and ZD. That's pretty neat. And then I added this slide, even though this is not a Zedification, but Spiffy and Spire are everywhere. So ZD does work with Spiffy and Spire. So if you want to do workload attestation, you basically, yeah, via the third-party CA support. So the OpenZD project supports third-party CAs. You don't even need to trust us. I actually didn't talk about that before. But if you wanted to provide your own certificate authority and your own certificates, you can actually do that. You can upload a third-party CA into the controller. And then when a device with that certificate tries to attach to the network, you will be able to authenticate and authorize those devices through that third-party CA. Zero Trust is a journey. This is the longest path on the Earth, which you can walk. And that is the journey of Zero Trust, because not everybody is going to go application and bed it right out of the gate. You're going to want to have some sort of tunneling application. And so we have these tunnelers that are built for all of our major operating systems, including we have a Kubernetes side card that's a little bit old now. If you tried it, let me know. And then, obviously, we have all the major operating systems in mobile, too. There is one really cool superpower of tunnelers. And this is private, authenticated, authorized DNS. So when you have a tunneler and when you have a Zero Trust application, one of the really neat things that I showed you before, that addressability, I can just make up the word Jenkins. Well, if I'm not doing application and bedded Zero Trust, and instead I have this little tunneler device that sits there, then what I need to be able to do is I need to be able to tell that operating system where Boatemic Boatface is, which is a legitimate domain that you can access through ZD, but is not a legitimate top-level domain, TLD. So Fluffernutter, you could make a service called Fluffernutter. Oh, I gave this at a B-sides event not too long ago, so I have a B-sides up there, too. You can make up whatever you want, and you can also shadow domains. So if you have a legitimate domain that you want to intercept first, and we do this with our Mattermost traffic, you can go to matermost.tools.netfoundry.io. When you're on the network, it lets you get into Mattermost. And when you're off the network, it just gives you a 403 forbidden. That's pretty neat. And you can turn it off at a moment's notice. So big tenant of ZeroTrust, having that identity, being able to authorize that identity, being able to deauthorize that identity very easily. It's also APIs for all this stuff. If you want to automate it, you can certainly automate it. This is just a given-to-you example of the journey continuing. I don't know if I like that slide anymore. This is interesting, though, because this is from 2021. Last year, I liked this particular document because if you look in the upper right, oh, let me big it. Yeah, there we go. ZeroTrust, as I mentioned, 11 times. So US government's all bought in on ZeroTrust. I don't know if anybody's in the really highly regulated space, but ZeroTrust is everywhere now. It's been a thing since COVID really started. It's gotten really hot since COVID started. And so they have some really good docs out there, though. So foundations of ZeroTrust. I like this diagram. Shows you the device identity. Shows you network and environment. All this kind of interesting thing. It's really thick if you want to read that PDF. I wish I should find the actual right. Somebody actually synthesized it for you. So I should find that link, and I should put it in here. So I'm sure everybody is like, wow, hey, let me get this. How do I get OpenZD? Let me put it in the shopping cart and take it home with me. So you can go out to openzd.github.io. That's where our docs are. We have a bunch of quick starts. One that's really, I should have made that slide way bigger. Two says, everything local, no docker. Everything local, I love docker. Everything local, docker-compose. And then host it myself. I just want to host it anywhere. So like, virtual private servers, ZD is really pretty awesome if you're in the self-hosted space and you want to make a VPS of your own. Takes very little. Like, I run these things on ridiculously tiny machines, free ones, and never even notice it. Once in a while, when I do something chuggish, I might get an IOPS hit. Lots of SDKs, like I talked about before. Those are pretty much ranked in the order of who uses them and how mature they are. And then Open Source Project. So go up there, hit the GitHub, improve this doc if you're interested. Here's my socials. Here's ZD socials. We're on a few of them. We've got a YouTube channel. Hit the 100 subscriber mark. Very big deal. So now I can say OpenZD. I used to have to have some, I used to say, search for OpenZD. But we hit 100, so we can get an OpenZD up there now. We're on Twitter, and Ziggy's also on Twitter. GitHub, obviously, discourse. I'm active on discourse. If you have any questions, you can ask me here. You can ask me on discourse. And that is everything. So before I go, if you think ZD's cool, oof, we need those stars. We need those stars. It's the measure of an amazing Open Source Project. We have 294. Is anybody going to give me a star? Come on, I need a star. I also have stickers. They don't look like that, but they look like this. So if you're interested in stickers, you can get stickers. That is my entire presentation, talking about Zero Trust and ZD. Happy to have any questions. All right? Great. If you see me around, say hi.