0:00 David Flanagan: Today we are unboxing the ngrok Kubernetes Operator. This operator lets you expose your Kubernetes services to the internet. Without having to deal with load balancers, port forwarding, or any of that nonsense complex networking. In under 20 minutes, you'll have a working setup with secure ingress to your applications in your cluster. So let's get started. Now there are a couple of prerequisites for you to get started. You're gonna need a Kubernetes cluster. As you can see here, I can run kubectl get pods, I see a control plane and a few other bits and pieces, but that is all this cluster was just spun up

0:42 of kind using, kind create cluster. Feel free to do the same. The other prerequisite that you're gonna need, and it's not gonna be a surprise, is an ngrok account. You can click the link in the description below, or go to ngrok.com. From there, you can log in where you'll be presented with this lovely welcome page, and this will give us access to the auth token that we need to deploy our Kubernetes operator. Okay, so the first step is to go to GitHub, where you'll find the organization ngrok and a repository called ngrok-operator. The link is also below in the description.

1:22 You can scroll down to the installation instructions where you can see that we need to add. The charts.ngrok.com repository. We can just paste this straight in and let Helm do its job. Next, we just need to set a few environment variables so that we can run the install operation. I am just going to create and install.sh file at a portable shebang and drop in our code. The namespace that I'm going to install this operator into is just going to be ngrok. We now need to provide two pieces of secret information. Now I'm going to pull these through using.

2:08 direnv. So I'm just going to remove them from this file and save. All right, so let's head back to our terminal. We can now run install. But before I do that, I just wanna show how I'm getting my secrets in. There is no magic here. I havew .envrc using one password secret references. I can run op run, printenv, and filter in for ngrok and you'll see that these are both concealed by the one password CLI. That now means that I can just say bash install.sh, where my secrets will go through to that script and be deployed

2:46 alongside the operator like so. We can now do kubectl -n ngrok get pods. And we can see that the container is creating for our operator agent and the operator manager. We'll give that just 10 seconds to get healthy. And voila. All right, so let the kubectl apply to deploy our workload to the cluster and run get pods. We can see that already. Our workload is happy. It's running, hopefully successfully. We can then do a port forward to the pod within the cluster. Pop open a new tab. And here we have our arbitrary workload. This is the ngrok versus the firewall game.

3:44 As you can see, the ngrok logo at the bottom runs around firing with little bullets to destroy the firewall. Now, I don't want keep this fun to myself. I wanna share this with the world, and that means making it available without a Kubernetes port forward. So we're gonna have to take a look at the resources that the Kubernetes operator provides. Select the right one to make this available on the internet, and our job is done. So let's start that before the firewall gets me. Let's go back to our ngrok API Resources. Now, I said, you only really need to know two, maybe three of these max, and

4:27 that still stands well, I should hope so. I only said it 30 seconds ago. But the two that we are going to focus on today are ngrok traffic policies and Agent Endpoints. The third one, which becomes more important as you roll out ngrok within your organization is Cloud endpoints. Now there's specific videos that I've already done on these two concepts, so I'll refer to those and you can go learn more. We are going to use agent endpoints today. Agent endpoints mean that I have some sort of agent here the ngrok operator, which is responsible for making this application available, or at least the

5:07 application will only ever be available for as long as the agent is available. Traffic policies allow us to determine as traffic comes into the ngrok network, how to handle it based on headers, locations, add in oauth authentication, anything like that to protect my applications. And you join the two together and you get the easiest networking, making things, public experience you've ever had in your life. That's a strange sentence. So before we get started on the ngrok traffic policies, we need to get ourselves an agent endpoint to make our application available on a URL that anyone can browse to.

5:49 We can use another one of my favorite commands, which is kubectl explain, and we can say what is an agent endpoint? We can then say, okay, what's the spec and everything that we need to know to craft this YAML is here. But you're not here to sit and watch me type out, so YAML, so let me pull one out the oven that I baked earlier, So I guess it's now time to show you the YAML. As you know, when you work with Kubernetes, we have to deal with so much YAML, and I always feel bad when I'm doing workshops and

6:26 trying to help people get over this. They spend hours upon hours drowning, hundreds if not thousands of lines of YAML. And you know, it's just the way it is with Kubernetes. So, um. Let's just crack on with it. Let's open our agent YAML. Eight lines. Surely not, surely I can't apply eight lines of YAML and endpoint and browse to my, I guess today you can. Just like the game, the ngrok logo is destroying firewalls and making networking simple. It does just take eight lines. We specify that this is an agent endpoint. We give it a name that is irrelevant.

7:21 We pick the ngrok domain that we wish to use. This could be an eng rock.dev domain like I've used here, or it could be your own custom domain that you've registered with ngrok Cloud Service. We give it the upstream URL in this case is simple Kubernetes service, and there we have it, or publicly available workload. So let's use the ngrok UI to understand what is happening here when we run that Kubernetes operator in our cluster we are essentially spinning up an agent. We can see here that my agent has been online for around 40 minutes.

8:00 The length of time that I've been working on this video, it's operator 0 17 0. You'll also notice that I have other agents, and that's because I use ngrok operator and my real production Rawkode Academy Cluster. And you'll see that more when I click on Endpoints because we have our rawkode.ngrok.dev, which is our game. We have the Rawkode Academy Zitadel. If you've ever been to the website and logged in, that powers the whole thing. The Rawkode Academy, API, which is a GraphQL Federated, API, across dozens of microservices, all powered by ngrok, the Rawkode Academy, Zulip a Code

8:43 Forge, and just some random demos. So it really is that simple. But that doesn't mean you can't do complex things when the time is right and the need is just So now let's take a look at ngrok traffic policies to see just how powerful ngrok can be. I. All right, let's refresh. Play my game. We've decided that this is still an internal prototype and well, we want it available for people to experiment with. Uh, we need to restrict who has access to it because, you know, we can't have anyone getting our ip, you know, especially since this entire

9:21 game is stored in a single HTML file. So we need to protect it. Now we've all been there. We want to stick basic authentication in front of it, but we all know basic authentication is essentially no authentication. So we're gonna need to do this, right? And we're gonna want to use OIDC. And at that point in time, developers heads everywhere go, because these things are hard. Very, very hard unless you're using ngrok. So as part of our agent endpoint, I have a traffic policy called OIDC like so. Three lines. I then have a traffic policy, CRD, called OIDC

10:04 this policy just says that on an HT TP request, we're going to use the open ID connect action. There are lots of actions. We'll get into that in a minute. The config for this action points it to the Rawkode Zitadel, my real production, O-I-C-O-I-D-O-I, my OIDC. For the Rawkode Academy. Now, this client ID and Secret are very temporary and ephemeral. They will be deleted before you even see this video, but I provide the issuer, give it the ID and secret and the scopes that I wish to collect. Let's apply this to the cluster and then let's go back to the game.

10:46 And you know what? I want to play again. Let's refresh this. Oh, something must have went wrong. Oh, I guess I'm gonna have to log in. So let's log in. Ta-da. The easiest OIDC you have ever seen in your life. Hands down, guaranteed, but no money back. So what else could we do with traffic policies? So here we have the ngrok documentation. We have a list of all of the actions that we can use as part of a traffic policy. I already mentioned Basic off. I'm now gonna show you basic off. I've already mentioned OIDC and showing you OIDC.

11:28 It's right there. If you don't want use OIDC, you can use OO. You can use Jot validation or you could even use saml. Saml. I know as well as that we can do extra logging. We can do forwarding. We can send customer responses, we can compress responses. You can build in circuit breakers, we can redirect, remove headers, restrict ips, or regions because we have access to common expression language cell. If you wanna learn more about that kind of approach, I'll put the link in the description below. I've already done the video. And we can do rate limits.

12:08 Let's come back to our game and hit refresh. I can play. I could play, I could play. And then for some reason, and to say to refresh, oh 4 2 9 2, many requests. Well, why is that? Because we modify the traffic policy on our workload to use the rate limit action only allowing one request per hour. Now, I'm not a big fan of this very generic HTTP response code with nothing to the user unless they understand what 4, 2 9 2 minute requests are. So can we make this a little bit nicer? And of course the answer is yes, of course we can.

12:59 Let's come down here to customer response. We jumped down to this example and you can pick one of whatever ones you want, but I'm just gonna pick the simplest one because let's chance of me getting it wrong. We'll come back over to our traffic policy. We'll drop this in. We will make sure this line's up. We will have a no sip today. I'm back in an hour like, so let's reapply. Go to our game as refresh, and now we have a custom page. Now, while I am sending a customer response with arbitrary HGML, you could also use Redirect to send it to another website where you have

13:49 tailwind and all your shiny front end stuff that I just don't understand. So there you have it. In under 20 minutes, we've deployed the ENG Rock Kubernetes operator exposed our ENG Rock conveyors firewall busting game to our ClusterAPI, making it available to the internet via OIDC authentication and even implementing rate limiting with custom error pages. All of this without touching a single load balancer. Dealing with port forwarding wrestling with complex networking configuration. It really was just that simple. Even applying the custom resources to the ClusterAPI wasn't that difficult. Authoring the YAML wasn't that difficult. You'll notice that this is a theme with the Eng Rock products.

14:38 We, they make the complex things simple. Go check it out today@engrock.com. Thanks for watching.