0:00 <Untitled Chapter 1>

0:24 Hello, and welcome back to the Rawkode Academy. This is the complete gate to Teleport, and this is a workshop number two. That means that for the next forty minutes, roughly, we will be taking a look at me, work through a GitHub document as available to everyone to work through in their own time to show and share some of the cool features of Teleport. Today, we are focused specifically on application access. We'll cover what that means as we work through scenarios. But first, I really just want to get started, show you what we're working with today,

1:03 and get started with the first task. These are live workshops. That means you're more than welcome if you're watching us live to put questions into the chat, say hello, anything you want. Just reach out and we'll do our best to get to that as quickly as possible. Now let's get my screen shared. If this is your first workshop, you can find all of these courses at github.com/rawcodeacademy/courses. You will find a directory there called teleport complete guide, and this is six application access because this is part six of the Teleport course. Let's scroll down. So I am,

1:20 Initial Setup (VMs, DNS, Pulumi)

1:51 for this workshop, and I I guess probably for all future workshops, going to be using the Acme slash less encrypt certificates with Teleport, which means there are domains and DNS records configured. I have done my best at the top of this README document just to tell you what those are so that you can replicate this in your own setup. If you are calling us directly locally and working through it in your own time, I would encourage you to do a search and replace for Rawkode.sh replace it with a domain that you have access to the DNS records for,

2:20 just to avoid any strange errors as you continue. I am using Linode for today's virtual machines. So there is a Pulumi, small Pulumi project available here in the directory. So you can just run Pulumi up as long as you've got the right credentials for the node exported in your environment. And that's it's gonna spin up a two node setup with just Ubuntu 20.4. Alright. My DNS records are all created. I'm not going to run through exercise one, but I will confirm that they do exist by running a dig t dot Rawkode dot SH. I have a wildcard configured, so I can,

3:04 and hopefully it can do anything. We get the same IP address and I set up for my worker node w one, which has a different IP address. That looks exactly like I expect. That means that when we install Teleport to these machines, it's going to pull in the ACME certificate. Now all of these workshops are standalone, so we're gonna kinda quickly fly through just the creation aspect. And again, just to make sure that everyone is comfortable with this and you know what you're doing, it does not hurt to run through the setup a couple more

3:27 Install & Configure Teleport Auth/Proxy

3:38 times. I'm gonna start with SSH ing to my control plane node. There we go. And we shouldn't have Teleport here. This machine has only been spun up around thirty minutes ago. There's nothing on it. This is a very generic and boring Ubuntu machine. We're just gonna follow all the commands. So the first thing I'm doing is I got better with us in the first Teleport workshop by not setting the host name. I expected the node to do this through the labeling. If we take a look at the automation here, we do add a label, which seems to set it on the backend

4:18 for the Linode portal, but doesn't set the host name of the machine in the SSH. And then the host name, which is a local host, and it looks really crap when you start trying to explore Teleport for the UI or for the CLI. So we're fixing that today. The first thing we do is set the host name that we want it to be. I'm gonna copy and paste all the boring stuff. We're using the Teleport Debian and Ubuntu package repository. What confused me and scared me prior to jumping onto this livestream not recording was that Teleport 8.0.0

4:56 has been released. It seems to be pretty new, but I don't think based on what I've seen in the release notes, should run into any problems today. Fingers crossed. Let's give that a second. The next thing we wanna do is configure this. So on the first workshop, we ran into a little issue around the secure certificate. Now I'm not gonna go into it in detail, but what the problem was because I decided just to record a tutorial, which should drop or be available by the time you watch this. Fingers crossed. And it's just because Teleport needs access to

5:32 the the root CA to be able to trust those certificates and they're shared. And most of my tests were in containers or using Kubernetes where I had volumes that shared those root certificates across the different agents. But when I did the workshop, I used Linode for the first time and ran into some problems and that those certificates weren't being shared across the different VMs. Of course not. We can just amend all of that and use the public DNS records and real certificates from Let's Encrypt. So what we do here is we say Teleport configure, which is just gonna tell Teleport to generate

6:01 Teleport Configure

6:05 base config. We did look at this in the first workshop. The parameters we can pass are just, hey, let's enable Acme. Here's the email address for the account or the name that I want associated with the certificates. Here's the name that we rest to use and dash o just tells it to save it to a fail. If we pop over here, we're not gonna return on the last one, so let's just do that quickly. And we are getting eight point zero dot eight zero again. That wasn't an accident. No. Just a thing. And we'll give that another moment. There we go.

6:38 And we should have access to Teleport version, which we do. So we run this configure command and we can see that it has created a config at the location we expect. And this is a pretty standard Teleport config. We've seen this now a few times. What's important here is that our proxy service has the ACME The YAML has the ACME key with enabled to yes as an email address to attach that certificate. Alright. Well, I'm happy with that. I'm just going to go ahead and start Teleport. And if we jump back to our instructions, that was the next thing.

7:23 We've got the example configuration, which you should see. And now we are going to continue on from what we also done to workshop one, which is your static token authentication. This is not something I will encourage in a production environment, but for these workshops, that is a great way to get started quickly. We will have a best practice video where we talk about doing this in a nice, safer fashion. However, what we want to do is grab this token and add it to here on the off service. It affects the indentation because that's all we

7:33 Static Token Authentication

7:58 ever do. And what we're seeing here is that we want to have a bunch of tokens available and the off service that allow anyone with access to that token to authenticate on a proxy and node basis. I'm gonna add one more and fix my fix my readme because we're gonna need it later and it says we're doing it there. Here. Oh, proxy node. I have fixed it locally. Just haven't pushed it. There we go. Even better. The proxy app and node. We wanna allow the proxy service to connect and speak to the Teleport cluster. We also want

8:36 to allow the app service to connect and speak to this cluster and the node service we want to allow to speak to this cluster. And the token is Rawkode dash workshop. I see Russell has joined us. Hey, mate. Russell is on the Discord. I've been talking about my audio and camera problems that have been affecting me for a week, but today we're really bad. So I'm hoping that I look and send all right. Feel free to give me a thumbs up if you don't mind. I'm gonna continue regardless. And so we have our Rawkode workshop static

9:12 token available, and we're gonna need that when we make, when we have other virtual machines, nodes, bare metal, whatever connector to our cluster. So let's save that and jump back over to our README. It should look something like this, which we now have. Oh, let me see through here. There we go. And now we can create our admin user. This is the user that we are going to use initially to set a few things up within our cluster. One thing that's different from workshop one is that we no longer have access to roles equals admin with Teleport 8.0.0.

9:36 Create Admin User & Web Login

9:52 And it's now broken down into you have to use editor and access. The roles admin is gone. You can have to record that, rerecord that entire workshop, but that's probably for the best anyway. And we're gonna add logins routes so that I can have route access to each of the nodes within the Teleport cluster. And we click our link, we're going to sign up. Now I have done some tests on this domain, so I'm gonna reuse my password. There we go. Password. And I'm gonna have to rescan and get my second OTP down here. And that should allow me to sign up.

10:35 There we go. Now, we have a zoom in. We'll see that we have access to the Teleport UI. We have one node listed here. Things are looking good. Okay. Now we wanna join the cluster. We can SSH onto the worker node. So I'm just gonna spot this terminal. H l root worker one Rawkode. Sh and we'll copy these commands like so. So we're setting the host name again, adding the Ubuntu or Debian repository and then installing the Teleport package. Alright. Install. I am providing the the config for this, but essentially, we're Teleport that we want to

10:46 Ssh onto the Worker Node

11:34 go and speak to this off server, which is our control play node, t. Rawkode. Sh. There's the off token that we added as a static token. We don't need the off service on any of the worker. Russell, audio is fine for me and I can see the difference between your t shirt and hoodie size of the light. That's good. Awesome. That's a win. It's rare that I'm getting them these days. Okay. So we've the auth service disabled. We don't need that for things that are joined on the cluster. Auth service runs on the first node. And then we enable the SSH

12:06 service because we do wanna be able to SSH onto any of these machines. So I'm just gonna copy these two commands, drop them in, and we should now have, if we browse back to Teleport and hit refresh. Correct. Alright. Debug in issue number one. So what we expected to see there was on our Teleport UI is that we would have the Control Blade node and one worker node. We didn't get that. It means it's potentially a problem. Saying that is not again. There you go. Okay. Alright. I'm not going to pay this this time. So

12:15 Debugging Node Join Issue

13:18 this did not happen during my tests. I'm just going to fix it later. It was the VIM. Secure. Restart. Oh, yeah. That changed the unit fail, so we will need to demon reload. Start Teleport or restart. Sorry. If we do a journal flu yeah. No. Okay. So my my certificate my certificate I think, actually, we're fine. What's happening here is let's say my joint token is not valid. So let's see what we're dealing with. See, it doesn't matter how much you test this stuff, does it? I think it's cool. That's incorrect. That's perfect. Rawkode workshop.

14:37 Rawkode workshop. Okay. Let's see if we have any logs here. Cannot join the cluster with role proxy token error not found off go. Okay. So I've configured. Uh-huh. Right. Okay. Gotcha. Let's stop Teleport. And this is blow away the Teleport directory and gonna remove that and secure because hoping we don't need it. I think I didn't restart Teleport after adding my token, my static token. So Teleport, Make sure our Teleport service is still running. And let's try this again. There we go. It has joined the cluster. Perfect. I I was nearly about to go down

16:00 a rabbit hole of debugging that I had absolutely no need to go down. However, restart Teleport after you change the configuration. That's very important. Don't make that mistake. Phew. Alright. Now we're gonna move on to exercise five. We're gonna take a look at the debugging application. This is just something that Teleport provides so that you can understand how their proxy service works, how it's modifying or mutating the HTTP requests. So you can see the headers. And it also does some really cool stuff with JSON web tokens and certificates that allows you to be able to consume

16:23 Debugging Application

16:44 the credentials being passed through the proxy service within your application. And one of those are really cool use cases here is if you're using Teleport with a GitHub authentication provider or any of the SAML based authentication providers like Google, AWS, Microsoft, etcetera, is that you can pull in that user data and the rules so that you can then use that and pass it on to all of your internal administration or backend applications. And we're gonna see if we can take a look at that. Something I've done different this time with the workshop is just provide

17:18 the solutions for each of the exercises. So if you just want to copy and paste the code, you can. But what we're gonna do on this workshop is gonna try and find the answers, which is gonna be weird because I kinda know them, but we're gonna go through the documentation. I you to walk away from this knowing that the documentation is there, how to consume it, and the way that you would find these answers in a real world situation. So what I've said here is that Teleport ships with a debug application that dumps some environment variables for you to inspect, and we

17:46 want to enable this application. We're just gonna go to a Teleport doc, then to debug. That's not the right one, is it? Dumper. Yeah. That's something else. Maybe that's later. I do dumper, you know what? It doesn't matter. My favorite page is reference. Go here, click and config fail. Everything you can turn on is commented and documented on this file. So there's no It would appear, and I haven't really searched for it previously, but there's nothing under documentations about this debug application. But I do know that it's there, we wanna play with it. So we go to

18:30 the reference, we go to the config, we can search for debug, if I could spell. And what we see here, and I'll zoom in, is the first hit, which is great as that. Boom. If I highlight it, you can't actually read the comment. Teleport contains a small debug app that can be used to make sure application access is working correctly. The app outputs JWTs or JWTs, I believe we're supposed to pronounce them. So it can be useful when extending your application. That means consuming the authentication and not rebuilding it into your application when something that's

19:06 already doing it. So what we wanna do is to enable this, is find the app service and our Teleport configuration and add a debug app equals true. So that's just my system d log. We're gonna go to our Teleport.YAML. We'll go to the app service, which we don't have. Alright. Okay. We need to configure the app service. So we can just come in here to app service enabled, true. And we know that we want debug app equals true as well. We can save that and I'm just gonna cat it and we'll compare it to what

19:27 Configure the App Service

19:47 was in the documentation to make sure we get what we expect. App service enabled and debug app true. App service enabled, yes, true, I think. I believe both work. We're about to find out. And debug app. True. What we can do now, restart Teleport. Make sure that we have no errors by popping into here. It doesn't look like we have anything. If it fails to parse the config, in fact, you get a pretty quick warning about it. And in fact, why not let us just break it? Let's see. Enabled equals fluffy kittens. That doesn't break it. I'll be surprised, but

20:26 let's go for it. Well, that's the YAML thing. Interpret that is true, isn't It's funny. Yeah. Okay. Let's leave that as true. Let's just add a fake setting. Sure. Restart journal. There we go. Pails parsing the config fail. YAML on marshall errors, lane 40 field fit setting, not found in the type. So on messing the weird YAML except in any value as a true or trippy value, you get really good feedback when Teleport is not happy with your config. So we'll just restart that. What should happen now, in fact, do we talk about it here,

21:16 is browse to the debug application. So we believe we've enabled it. And the way that we can confirm that is to come back to the portal and click on applications. And you'll see that we now have access to the dumper application. So what I like about application access on Teleport is that when we set the app service up is that it uses wildcard DNS to actually give resolvable names to all of your applications. You can see we can use dumper. T. Rawkode. Sh actually just browse to this application. So if I just did dumper.t. You're seeing there was a whole bunch of

22:03 redirects there. So what happens is when we go to that webpage, it's checking to see if we're logged into Teleport, makes a few calls, gets the certificates, approves them. And then when it's happy, that should back out to the application that you actually want to see. The Dumper application here is just showing us the HTTP request stuff. So we can see, we have a GET request, we can see the host. And this is the proxy host. You know, we do have the x forwarded for information down here. So if you've worked with HAProxy or NGINX in this configuration, you should be

22:36 relatively familiar with these headers or I guess most of the buzzers as well. We have accept stuff, which is pretty common. We've got access token here and we've got our Teleport assertion here. There is a whole bunch of stuff here. Let's jump back over here. So the last thing we want to do here is just we want to decode this token. Actually, I want to dissect and understand what I have access to. No. We haven't configured this Teleport with any enterprise level authentication, right, GitHub, Google, etcetera. So I'm not gonna get a whole lot back out. You can

22:57 Decoding the JWT

23:15 imagine how that would be consumed. Next week, we do have a tutorial on configuring Teleport. So in Teleport open source, you get the GitHub authentication module for free. So as long as you have a GitHub organization with some teams, you can use that to integrate and log in to your Teleport instance. But for today, we're using local user. So I'm gonna copy my Teleport JWT assertion, which is just the same as the access token up here for the record. We're gonna go to jwt.io. This is like the de facto say if you're ever doing JWT stuff and you just

23:50 be able to debug why it's not working, just go here because it has this thing where you paste it in and it will give you all the decoded headers, payloads, and signatures. Now, if we know the private key, we can drop it in and it'll tell us whether this is synced correctly or incorrectly. Not really worried about that right now. What I really want to emphasize and show you is that we have the expiration time, we have the issuer, which is just our Teleport here, p.rawkode.sh, and we have the roles, the username, and the subject is the same in Jotlin. So you'll

24:22 often see sub and username together and the same value. But we can see the roles. We can see I'm an editor and I have access permission. These are the roles that when I did the T control, Teleport control, I don't know how to say that, users add, we said these are the roles we want to help these users do. The Teleport allows you to define your own roles and throw in more metadata there. We will have an episode, we'll have a workshop and a deep dive into RBAC in a couple of weeks time, but you can see

24:50 how we're getting this information. So if you can validate the JWT and the signature, you can trust that the information you're getting back in this JWT payload can be carried and passed onto your application and you can have a really cool authentication model integrated with Teleport. Sweet. That was relatively without hiccups. Now, if you take a look at our solution, that's exactly what we did. So on the Teleport server, we modified the Teleport. Yaml file. We added debug app true under app service, which looked like this. We restarted Teleport and we are done. So let's try and do something

25:30 Add NGINX App via Configuration

25:32 little bit more interesting. Let's install NGINX onto our Teleport server. We'll add NGINX as an application to the Teleport cluster. We're then going to go in and modify NGINX to only respond to requests on the private IPv4 address for the server, or even just onto 7001, whatever, entirely up to you. And what we should be able to do is actually just confirm the NGINX still works through the application access, but will not work through the nodes public IP address. Cool. So let's do an apt install NGINX. If we browse, we'll give this a couple of seconds to

25:34 Install Nginx onto Our Teleport Server

26:16 finish first. Ninety nine percent. Come on. It's like a software developer project where my teammates says it will take an hour. Be clear. I'm guilty of that too, actually. There we go. So now we installed NGINX on the control plane, but we can't actually browse to it right away because this is our Teleport server. So what we're gonna have to do is come into our NGINXconfiguration.conf, find the server block. Oh, it's gonna be in sites available perhaps. Yeah. Okay. Engine x, sites enabled, find default, opt down. And I'm just gonna modify this to run on port eighty eighty

27:28 on 8,080. I would suspect NGINX hasn't started yet, so we don't have any logs. But let's just do a restart NGINX. And hopefully now we can do a t.Rawkode.s h port 88. No. HTTP. That time something went wrong. I think that's just been silly. Let me grab the IP address of this machine. What was happening with the t. Rocket. Is it? Not important. We have an NGINX page here. So our mission is to add NGINX as an application to the Teleport cluster. So we're gonna go to the documentation and we're gonna try and work out how

28:41 Add Nginx as an Application to the Teleport Cluster

28:50 to do that. So we can click on application access gates, connect applications. And if we pop down here, it's gonna walk through some of the stuff that we've already done for today, you know, adding tokens. Now you can use short lived tokens for the application proxy process that you can run. We're gonna configure it straight into the Teleport. Yaml for now, we don't have to worry about that. If we come down to start an application with a conflict now, because this is a server process and we have all of this stuff available, we've already added app service ID bug true, is

29:31 that we could just grab this syntax here for providing a list of applications to expose from this machine and modify it to suit our needs. So we can modify our Teleport. Yaml. We're have to do so much reinventing here. So we've got apps. Let's try and get rid of some of the comments from there. I'm gonna remove anything that's optional. It's all optional. This is all you need. So we need that to align. There we go. So we say apps, we give it a name. I think it would be fair to call this one NGINX,

30:09 which is available on this local machine on port 8080. So we can just use local as 8080 we save this. You haven't seen it working yet, but being able to expose things from the machine through the config is really, really easy. Just needs the name and then GRI and Teleport will handle the rest. We can do a system control, restart, Teleport. And if we take a look at the logs, we should see things are still happy. We've got our Oh, I kinda missed it. Where'd it go? There we go. This info lane here, apps first down as

30:57 sixty days. So we're now running an app proxy server here. And if we pop over to this and hit refresh, we now have our NGINX application here. You can see the DNS name has been generated for us, NGINX. T. Rawkode. S h, and the labels. These are added by Teleport to seeing how does this application get added to the configuration. So let's just copy and paste this. We can also have launch, I guess it doesn't really matter. It's gonna do the authentication dance to make sure that we have access to this application and now we can browse to it via

31:32 nginx.t.rokode.sh. Now, something I haven't shown yet is what happens if we do that at a private tab? Well, what should happen is we get the Teleport login. We cannot use that name. We cannot go through the application proxy service without being an authenticated Teleport user. Very cool. Okay. The last part of this exercise as well. Okay. Sorry. The second last part is Okay. We don't want the public to have access to this. So you can see here we go through the Teleport service, but let's go through the node IP. There's the node IP. Yeah. We did open

32:16 that. And I can close this one. And we don't want this available. Anyone has it, the node IP can browse their application. We're considering it relatively sensitive at this point in time, so we don't want that to work. Okay. So we can modify our default engine next thing here. What we can say is listen One. And I can just remove that. Right? Who's actually doing IPv six anyway? But now we can say lesson on local was only hopefully oh, top 400 x. Hopefully, I haven't broken this. Looks alright. And if we do a curl localhost

32:27 Restrict Public Access to NGINX

32:59 eighty eighty, we get a response. If we pop over to here, the IP address one, we have lost it. Right? This NGINX application is no longer publicly available. And the last part of this exercise is, well, is it available via the Teleport proxy? And the answer is yes. Perfect. So that is how you take a application running within your infrastructure. You bind it to a private interface. You just remove it from the Internet and expose it through Teleport using the really great application authentication proxy. Russell, I just tried that. Cool. I hope it worked. All right, exercise seven. So

33:48 Add Grafana App via Configuration

33:50 let's do this. So definitely let's try and take, you know, NGINX is great, but you know, one of the most common use cases I have to use this specifically, and I'm assuming everyone is the same is that Grafana is something that usually has access to a lot of monitoring and observability data. We run it on public interfaces because it's easy, but at the same time, we probably wanna restrict access to it depending on what we have there. So we are going to install Docker on the server and then pull the image and run it. And we're gonna use Docker

34:26 port publishing that is bound to the private IPv4 or the local host address. And then we'll add this to Teleport. And the one twist we're doing with this one is just to show off some more application features is that we can modify that DNS name that has been generated for us whenever we add the application. But here I'm doing gnt. Rockode. Sh or g. T. Rockode. Sh. Now, whenever I need to install Docker, I go to get. Docker.io and I grab this. So we take off the dash o and just paper straight to bash. I think we just need to give this

34:53 Install Docker

35:09 thirty seconds and then I'll be able to pull the Grafana image. We look at the solution for the last one. There we go. For the solution, we pretty much did exactly the last we just announced install engine x. We added engine x with the URI here, although I was actually using port 80, not important. And then we listen on the private IPv4. Or you oh, actually, I used one two seven, but I could have used the private IPv. And then we did confirm that it still works. Perfect. We're still waiting on Docker just now. Won't

35:46 be too long. Oh, and my ferret is awake. Okay. Cool. We have Docker. So let's do Docker container run dash r m dash background dash publish port. And I'm gonna be very specific here. And when we use the port syntax with the IP address, it's just telling the interface to listen on. We also want to run, is it just called Grafana? Or is it Grafana Grafana? Yeah. I think it's Grafana Grafana. I could've looked at the solution, but I'm trying not to. Yeah. There we go. Grafana Grafana Grafana. Grafana, Grafana, Grafana. I think it's just that. Let's see.

36:55 So what we're gonna do is we'll pop over to the oh, I closed it. Grab the IP address again On port three thousand. And nothing works. Good. If we do a container l s, we should hopefully see a happy container. We do it up for nineteen seconds. Compassionate swaddles. Cool. I'll take it. If we do a curl on local host, let me see if we actually get a response. So Grafana is running in a container with a very specific published port to the local interface that is not available to the external world, but we want people that we have trust

37:45 with, that are authenticated with Teleport to have access to this application. So we're gonna continue as we did with NGINX and we're gonna go into our application config. We're gonna add a new app, call this Grafana, the URI local host 3,000. Now what we said well, in fact, let's just get it running first and then we'll change it. Restart Teleport. So what should happen now is I should be able to because I know how the naming structure works. It's pressed to httpsgrafana.t.rockode.sh. And after a little bit of an authentication dance, we should get the login page for

38:31 Grafana. Looks good. Well, the exercise said, look, we don't want it available on grafana.t.rawkode.sh. Perhaps people know to check for Grafana on sub domains, or we just have another reason for one not available elsewhere. So how do we control this DNS? Well, let's go back to my favorite page and the documentation, reference, no, setup reference, contact fail. We can pop down to the app service, and we'll see that we actually have all of the fields that we are not using being commented on to tell us what to do. We can tell it to escape and secure

38:37 Customize App DNS Name

39:17 certificates if we want. If we're running something that has self signed certificates on our server, which is quite common for private stuff, especially if it can't pass any of the ACME certificate requests or process. We can modify the public address, which we are going to do. Labels and commands, we can obviously play with later, and there's some redirect stuff that we can talk about for applications such as, like, WordPress that do a whole bunch of redirecting based on whether you authenticate to trying to get to the admin portal, some of the assets or doing internal redirects to, you can handle all

39:47 of that. But right now, all we want to do is modify our Teleport. Yaml, change the public address to g.t.Rawkode.sh. Restart Teleport. Pop over here. We'll change this g to a t. There we go. Oh, again. There we go. I think it's admin admin. Right? Yeah. New password. I don't know if you can figure that. It worked. Okay. Let's pop open a solution, make sure we haven't missed anything. So I did install Docker with Kernel Bash. My run command was pretty identical to that, which is good. And we use the public ADDR to make sure

40:51 that we can control naming of our application. Okay. We've got a couple more things to do. What if we want semi public access? This is an extremely contrived scenario that I'm gonna reuse on gitx and admin page, but you can use Teleport and, you know, your web server to restrict access. You know, we got with Apache, we have HD access. Within the next, we can add location blocks where we can just say, actually, you don't have access to this from certain IPs or without certain headers authentication, etcetera. So we're gonna try and set that up. It won't take us too long, but

41:03 Semi-Public Access

41:37 our secret application is that we'll we need NGINX installed first. Oh, fat. I see. We're gonna do this one on the worker node this time. Okay. I I haven't mentioned it in the exercise, but I'm pretty sure I meant to. So I will update that. And I'm sure the solution has a quirk that I want to cover. So we're gonna do it this way. Okay. So let's jump over here. We're on our worker. We don't have NGINX. So I'm going to do I have to install NGINX. The next part of this is that we want to set up our secret admin page,

42:28 Set Up Our Secret Admin Page

42:31 which I'm just going to create an HTML file in the web root. We're waiting for that 1% again, aren't we? I wonder what it's doing. I think of the man pages for engineering, if that's what's actually installing it. Although I must also say these are really small nodes. These are the nano core ones. So I'm actually not throwing too much power at this, which is probably why it's taking a little bit longer. Alright. There we go. So here is my admin page. With that, let's go to our www HTML, Cat admin. There we go. Wonderful stuff.

43:32 Restart. If it doesn't start automatically, for sure. Okay. So let's confirm w one Rawkode. H. There's no yep. There we go. There's a page. And we can just browse to admin.HTML and we get our really secure admin page. This is not what we want. Okay. Where's my to do list? So we want to modify the NGINX virtual host or site, whatever you wanna call to block non local traffic to the admin page. Okay. Let's do that. Enabled. Here's our default. Pop down here. And we can do location admin dot HTML. Rather than look at my solution, I'm going

44:51 to Google it. Well, yeah, there's my search from there. There we go. Because this this is this is how you find the answers to stuff. Mean, you don't remember off the top of your head. We go to Google. And I'm pretty sure it's just allow and then the cider. Hello. Let's just try. That's the only one I clicked on. Alright. Okay. Hello. +1 27. Not 1. Yeah. I think that's it. Restart it. Not yelling at me. Yeah. Okay. Let's have a look. It didn't work. Alright. We're looking at my solution. I forgot that denial. Is this middleware?

46:24 Alright. So then nginx place enabled default local. Restart. Alright. So let's there. Perfect. So we've blocked admin.HTML. We still have access to the homepage. Now we're doing this for a very superficial. We expect the request to come from the local machine. And that works all right in this scenario. Russell has lost access to his admin page. We're gonna fix it. So, yeah, this works really well. Having that denied there, it's just a really simple way of protecting access to certain components. Wirecards work really well for NGINX and the patches where you can really make this work,

47:18 where you have something that as public, 90% of it, maybe 50% of it. But there are components of it. You're like, gosh, I really don't want that exposed. Maybe there is legacy application. You don't want to extract it out to a new thing yet. Like whatever your scenarios are, this works really well. And you can do this through anything that has layer seven visibility. So even if this was in Kubernetes, you know, rather than like an NGINX, then I you could build this up to you know, Selim network policy or whatever. So lots of different ways you can do this,

47:46 but now what we want to do is regain access to the service. So, hello, welcome. Thank you for joining the workshop today. Okay. So now we need access back. Now, I'm gonna show you how it doesn't work first. And that you'd be very tempted to come into this and add our app service. Enabled, true. And you'd say we we have an app that we want to expose through the Teleport cluster, which has a name of admin with a URI of HTTPS. Oh no, sorry. HTTP localhost. Then change the ports that this session is running on port 80 and saving that. Now,

47:47 Expose Worker App via `teleport app start` Command

48:45 of course I even attempted this the first time. However, there's a bit of a situation and that if we do a system control, we start Teleport. Teleport is that it crashes and we get some errors there. But it turns out that we can't expose applications in this way, with this node configuration. Teleport, if it's not running the auth service and the proxy service cannot run the application service on the node, you actually have to go a slightly different route, which is to use the teleport app start command, like so. So this runs application proxy that works in just this mode

49:22 The Teleport Start Command

49:33 and allows you to export your applications and you would run one of these for each of your applications you want to do. I'm not gonna do it just now and create a unit fail and all that. We just kinda wanna get this working, but we could do an app start and we know our token is Rawkode workshop. And we know that our auth server is t.rawkode.sh. And now we just need to name, which is admin and a URI, which is http localhost. What did I get wrong? Maybe I don't need the 38. Maybe I do. Oh, no. I've I've broken

50:13 Teleport. Which need we need for the tunnel. Teleport happy. Teleport is happy. Okay. So let's come back to this. Maybe that's. You're very very We're look at the solution again, aren't you? Oh, then they can't have my tunnel. It's my teleport running. Yeah. Alright. Let's just look. I did document this here that when running Teleport process as an application proxy, it's much easier to create a unit file, which I would encourage you to do. The issue for the thing that I mentioned is here. So at the start has exit and someone from Teleport has turned in to say that this doesn't work

51:16 and you need to run proxy service and app service in separate processes, which is fine. You can see that they have off service null here. So now we just do a little bit of tidying up. I pop over here, here's my start command. Did I get something wrong? Oh yeah, four forty three, not 38. Because we have a TLS version of our thingy running. Okay. That worked better. Trying to change the command. Nope. Great thing about copy and paste. Okay. So that was the exact same command. I just got the port wrong. So it's Teleport app start. We give the

52:00 application a name, the URI to find it, token, and the off server. That's now running as quite happy. So we're gonna pop over here. You can see our Grafana and there we have our admin at launch. Medication dance. Oh, actually, I found this earlier. It doesn't work it out. Let's try one more time. Admin.p.Rawkode. Oh, no. It worked. Okay. I have trouble with the admin prefix. It wasn't resolving. And I could actually like, when I run deg admin.t.rawkode.c, it just wouldn't resolve at all, but only admin dot that appears that was just a temporary thing. So now we have our application

52:15 Debugging App Access after Restriction

53:08 here. And if we go to admin.HTML, we have forbidden. That wasn't expected. Let me make sure I got my rule correct. I'm just gonna open a new thing. Mhmm. Internet. It's enabled. Default. So what's my I just wanna make sure that dot 0 dot zero. We could be coming across the network. I'm gonna do this. I'm gonna restart my application. No. I wanted to restart engine x. That's the wrong course. Restart engine. And there's a really good way to debug this if it doesn't work. There is a. Re log. Think that's right. No. Relate log.

54:39 Yes. Internet rewrite log on. There we go. If we can now come to here monitor our error log, we should see if we still get a deny why we got the deny. So let's force the deny through w one. Yeah. This is me going to the node directly. That should be from my public IP address. We look here. Our client 82 has been denied, which is what we expect. And if we come through admin. T, we're still being denied. Ah, okay. So it's coming over the IPv6 address. We can fix that. So let's just make one final modification

55:54 here. We're actually going to allow one tail. There we go. Now coming through the Teleport authenticated proxy, we have access to our admin page, but the public world does not. I will update the workshop with me just so that the correct thing is there, and this already is. No. Okay. Cool. And so I can get that fixed. But that's a really cool application and you'll see it for the Teleport application I really love that semi private public thing, just leveraging NGINX, Apache, anything like that to block the things that we don't want people to have access

56:42 to. We're just gonna take a look at one more thing and then we'll finish up today's workshop, which is well, actually, what if I need local access and I don't wanna have to go through the Teleport system? Can I use T control to build to do this? And the answer is yes. So we can do a TCTL auth And that was my old name from workshop one. We're gonna authenticate against ECCL off server. There we go. I think I got that wrong in the last workshop too. Oh, no. I'm using the wrong command, aren't I?

56:50 Accessing Apps via TSH CLI

57:49 Nope. I have no idea what I'm doing. T s h off. Why can I not remember anything? Log in. There we go. Proxy. Okay. Dot s h. It's gonna ask me for my username and my password. Sweet. Grab that from here. Rawkode Teleport. Copy. My OTP. Back in oh, think I one there. I'm gonna have to grab it from this browser. There we go. And I probably copied the wrong password, that thing, because I have issued the wrong one. So password. OTP. Haven't seen that before. I am I could delete all of that. I'll try that one more time.

59:59 Do I need the whole thing? I don't think you do. I think it just wants the domain name. Yeah. Because I already add that. Let's try again. It won't let me down. Password. OTP. Just in case we're going to add and secure. Because I I'm I'm not sure. The joy of doing things live. Address. Okay. We are running Teleport eight. I wonder if because my client is older. Yeah. There's eight zero zero there. We'll try this. If this doesn't work, I'll pretend to go through the process of what should work. Again, we shouldn't need unsecure because

1:01:51 we're we're raising less encryption certificates here. Our proxy is t dot Rawkode dot s h. Let's grab this password again. Copy. Second to FE. Paste. Alright. We are now authenticated with our our Teleport cluster. Now we can run ectl apps ls, and we can see each of our applications. We take a look at that app sub command. No, that's not very one. Maybe it's TSH app. Yep. There we go. I never remember when you're supposed to use TSH and T control. But we can do an apps login. We will log in to our let's look

1:02:50 at what does the thing tell me to do? Our seeker application first. Okay. So that's called admin. And you will see that what TSH is now doing is pulling down this certificate information that we need to do the the TLS handshake with the application, with the Teleport Proxy Service to be able to browse to that application. And now if we copy and paste the curl, we should be able to hit admin. HTML, and we get the admin page back. The last thing we want to do is just take a look at our dumper. So that can just be our TSH apps

1:03:31 login again, dumper, and we're just gonna get the same information back. Now you can imagine if this was an API that you're working on a Kubernetes cluster, you wanna be able to write tests or something like that. This is a really good way to get that configured. And we can see all the same information that we need to. And we can also do an apps logo dumper. It's just gonna remove our certificates, our keys, and etcetera, and clean up things up so we don't we no longer have access to it. So Russell is asking, is there a CLI command to check the

1:04:07 A Cli Command To Check the Version of the Client and Server

1:04:09 version of the client server? Like, you can definitely do it to get the version and check the client version. I wouldn't think there is any way to get the server version other than a TCL status, which is gonna give you the version here. But that would be great if I could just run like a, I guess because you can be authentic to against multiple clusters. Yeah. Definitely feedback for the Teleport team. It would be nice to get a warning to see in the client and server different versions before getting really, really bizarre messages that don't make a lot

1:04:41 of sense. Like, hey, failed to authenticate with a handshake and a fail. Like, that doesn't tell me anything. It was just sheer chance that I remember the versions were different. So, yeah, room for improvement there. But that's it. Thank you. Well, let me pop back over. I know. I had a repo. But, yeah. Hopefully you enjoy this workshop and we've got another one coming on Kubernetes. Stay tuned for that. Check it out. Run through it in your own pace. I will get the typos and random things that were messy today, especially the IPv6 on the deny block for NGINX fixed.

1:05:19 No one else has to run into that. I hope you found that enjoyable. Teleport is a wonderful application. App access has so many different potentials that make it just wonderful for exposing things like Grafana, backend portals, admin portals, etcetera, from your infrastructure in a secure fashion. So thanks for joining me today. I hope you have a good one, and I will see you all soon. Thanks a lot. Bye.