About this video
What You'll Learn
- Restrict Prometheus metrics with ngrok traffic policies by matching the /metrics path.
- Use CEL geo variables to block or allow requests by country.
- Return a custom 404 response with CEL-interpolated country text for /uk.
Using ngrok Traffic Policies and CEL expressions to lock down a Deno API: restrict the /metrics endpoint to specific IPs, then geo-restrict /uk to United Kingdom visitors with a custom CEL-interpolated 404 response.
Jump to a chapter
- 0:00 Introduction & What We'll Cover
- 0:26 The Demo Application
- 1:49 Basic ngrok Setup
- 1:51 Exposing the App with ngrok
- 2:32 Testing the Basic ngrok Tunnel
- 3:32 Introducing ngrok Traffic Policies
- 4:14 Applying the First Traffic Policy (Global IP Restriction)
- 4:39 Testing Global IP Restriction
- 4:54 Understanding the Policy File (Initial IP Restriction)
- 5:38 Using Common Expression Language (CEL)
- 5:52 Exploring ngrok Documentation & CEL Variables
- 7:17 Applying IP Restriction to /metrics
- 7:20 Policy: Restricting IP by Path (/metrics)
- 7:41 Testing Path-Based IP Restriction
- 7:49 Demonstrating Path-Specific IP Restriction
- 8:28 Policy: Implementing Geo-Restriction Setup (/uk endpoint)
- 8:46 Exploring Geo Variables in Documentation
- 9:22 Initial Geo-Restriction Policy Attempt (Deny by Country)
- 10:25 Testing Initial Geo-Restriction (Debugging Required)
- 10:58 Debugging and Refining Geo-Restriction Logic
- 11:00 Refining Geo Policy: Add Path Scope (/uk)
- 11:17 Using Custom Responses Action
- 11:30 Configuring Custom Response with CEL Interpolation
- 12:30 Testing Corrected Geo-Restriction Policy
- 12:31 Demonstrating Corrected Geolocation Restriction (/uk)
- 13:41 Overview of Other Policy Features
- 14:14 Conclusion & Call to Action
Full transcript
Generated from the English captions. Timestamps jump the player to that moment.
Read the full transcript
0:00 Introduction & What We'll Cover
0:00 Today's video, I'm going to show you three pretty cool tricks to enhance your application using ngrok. We'll be using ngrok to protect an endpoint, to restrict an endpoint using geolocation facilities, and to improve the security posture of our application. Let's have some fun. Okay. So, let's start with the application first. Now I've kept the application super, super simple. It's just here to enable us to dive in to ngrok features. Now that's maybe just my excuse for giving you an API with black text on a white background. But what we have here is a Deno application
0:26 The Demo Application
0:50 configured with a router and some Prometheus metrics. We create a path counter so that in each route within our application or API, whatever you wanna call it, and we increment this based on the path that we hit. As we hit the home page and hello world, we increment. As we hit slash howdy and howdy world, we increment. These metrics will also be exposed on slash metrics. And one of the first things that we want to do with ngrok is just protect the metrics endpoint from unsuspecting traffic. We then listen or bind our application on local host 127001.
1:29 So this is a private by default application on port 8,000. Now as private as I run it on local host and as we push it to production and to maybe a container or Kubernetes, it would be private to the pod unless we hook an extra infrastructure concerns to expose that to the world. Now because we're gonna be showing off ngrok, what we need to do first is run this application and expose it with ngrok. So here, I have a README file with a d n r run command that allows me to run my API. Like so.
1:51 Exposing the App with ngrok
2:05 I'm then using ngrok locally to say, let's expose port 8,000 over HTTP on my domain, rawcode.ngrok.dev. Now I'm not gonna guide you through the installation of ngrok locally. You can use Next Shell, your system package manager, a container, or whatever you like. For me, I'll do run block. So now let's head over to our web browser and see what our wonderful application looks like. So let's go to localhost port 8,000. And here we have hello, world. We can now change that to Howdy, and we get Howdy World. One more time, we go to metrics, and
2:32 Testing the Basic ngrok Tunnel
2:51 we see that we've had both of these pass one time. We can also go to ngrok.dev like so. And I accidentally went to metrics, so let's go to route, go to howdy, and then pop back to metrics, where now we've had both pages of the application twice. And if we refresh the local one, you'll see that these are the exact same application. All we've done is use ngrok to make this available on the public Internet. Now as cool as that is, ngrok has been around for over a decade, and we're all fully aware that ngrok makes this workflow
3:29 trivial. So let's take a look at a recent feature added to ngrok cloud, traffic policies. Okay. So, again, just like a moment ago, ngrok is running. I can browse around via Rawkode.ngrok.dev between the home page and Howdy. Here, I have a GCP Cloud Shell where I can also curl ngrok, Rawkode.ngrok.dev, and I see hello world, Howdy, and, of course, metrics. What I want to do now is stop ngrok and show you the second version of this command. Here, we're going to run it just as we did before, the exact same command. However, we're going to add
4:14 Applying the First Traffic Policy (Global IP Restriction)
4:30 our traffic policy file. And now if we hit run, we can sell browse locally. However, from GCP, the connection is immediately rejected. Why? Well, let's take a look at our traffic policy file. Here, I said, on a TCP connection, we wish to restrict the IPs with enforce. We could set this default to test out new policies. However, for this simple example, we're gonna enforce it by default. And these are the two IP I p v four and the infamous I p v six, for my machine on this network. Meaning, if anyone else tries to access our
4:54 Understanding the Policy File (Initial IP Restriction)
5:27 application, it's going to fail. But, of course, what's the point now? Right? It's the exact same as if I just ran it locally bound to 127001. Now the secret sauce of traffic policies is the common expression language. We can actually modify this to only restrict a certain endpoint. So let's go take a look at the ngrok documentation. This is the traffic policy page, which is currently in preview, but we like to fly things on the edge and unstable as often as we can. It makes things more fun. We can pop down to restrict IPs where we'll see a nice example of how
5:52 Exploring ngrok Documentation & CEL Variables
6:13 to do this, very similar to what I have done in my application. But we want to tailor this using expressions. We have access to a whole bunch of variables within the common expression framework, which has been enriched or augmented by ngrok to provide even more context. If we click on connection variables here, you'll see that we only have a access to a small number. Now that's just because we were using a TCP connection and not HTTP. So we come to HTTP and overview. We can click on expressions. We can click on request variables. And now we have the understanding
7:01 of an HTTP request. Okay. So let's scroll down, and then we see request URL and request URL path. Oh, that's port. Path. So we copy this, and what we want to do is push actions down, but correctly formatted, and drop in our expression. We can update this to be slash metrics. So now what we're saying is if the request path starts with metrics, restrict it to these IP addresses. So we can kill our ngrok process, head back to the README, and say run. Like so. Now if we head back to the service, we can still get to howdy,
7:49 Demonstrating Path-Specific IP Restriction
7:53 we can still get to hello, and we can still see metrics. If we pop over to a GCP cloud shell, we can run h t t p s, Rawkode, ngrok. Dev, we get hello, we get howdy, but we don't get metrics. And we can actually see the request was blocked by the endpoint's IP restriction. Sweet. Okay. Now we're gonna try something a little bit different. I've added a new endpoint to our application slash u k that says, hello, u k. We're gonna add a geo restriction to this endpoint so that only the people in The
8:28 Policy: Implementing Geo-Restriction Setup (/uk endpoint)
8:43 UK can see The UK page. Heading back over to the traffic policy documentation, we can click on expressions overview, and we'll see that we have access to connection geo variables. Now these actually are available on TCP and on HTTP. However, we wanna send a response over HTTP, so we're going to continue using on HTTP request. We click on this. We can see that we have access to city, country, country code, latitude, radius, etcetera, etcetera. What we want to do is filter by country. So we'll copy this expression and head back to our traffic policy doc.
9:22 Initial Geo-Restriction Policy Attempt (Deny by Country)
9:29 Here, we can add a new expression like so, making sure we got the right formatting. And I'll set this to United Kingdom. Next, we wanna add our actions, and we can add a type deny with a config of status code 404. We can just make it look like this page does not exist to anyone outside of The UK. Now to find the deny and disconfiguration, you can just click on actions, deny, and you'll see that status code is the only accepted property, and there are plenty of examples throughout ngrok's documentation. Great work, ngrok. Heading back over here, we can go to
10:25 Testing Initial Geo-Restriction (Debugging Required)
10:27 our README, make sure our application is running, and run ngrok again. We head over to our browser. It looks like it's already tried to refresh, and we're getting a four zero four. Now that's because we didn't restrict the path in which we want to block the country. And I'm kinda glad that it has blocked the country even though I am in The UK because it means that we have to debug this and work out how it represents The UK as a country name. What we'll do is say that we only want us to apply to slash UK and
11:00 Refining Geo Policy: Add Path Scope (/uk)
11:03 we will stop ngrok. We'll hit run, go to the browser, and our howdy works, but our UK does not. So let's modify this. And instead of doing a deny, we're going to do something else. We're actually going to send a custom response. We can configure this much like we did with the deny. And to get the properties that we need, we'll head back to the documentation and click on custom response. We can continue to set a status code, only this time we can set content and headers. So status code, it's gonna continue to be four zero four. The content will be some
11:30 Configuring Custom Response with CEL Interpolation
11:50 HTML string. And the headers, we probably want to set content type, and we'll leave that as text plain. And we'll just say, sorry, This page is only available in The UK. You are from Congeo country. Now we know that this should work because it tells us here in the documentation that the cell interpolation is enabled on this field. So let's go back and run ngrok again. We can head back to this page and refresh. And it tells me that I am ending in United Kingdom, which just makes this all a little bit more amusing for you.
12:31 Demonstrating Corrected Geolocation Restriction (/uk)
12:51 Okay. So let's head back over here. And, of course, there's always something silly. We want to block when the country is not The United Kingdom. So let's kill that first process, rerun ngrok, head back to the browser, and refresh. And, of course, we get hello UK. So let's run curl htpsRawkodengrok.dev/uk. And now our Cloud Shell tells us that it cannot access this website because we are in Belgium, but we haven't affected any other page. Perfect. So I hope you see just how powerful traffic policies for ngrok can be, and we've barely scratched the surface. Go explore the documentation where you'll find examples
13:41 Overview of Other Policy Features
13:52 of JWT validation for your endpoints. You can disable and secure TLS ciphers, enable compression, and add and remove HTTP headers to request all through a simple YAML interface. I hope you enjoyed this video. Please remember to thumbs up and share the video with your colleagues. Until next time. Have a great day.
Technologies featured
Stay ahead in cloud native
Tutorials, deep dives, and curated events. No fluff.
Comments