Traffic Policy support for the Kubernetes Gateway API
Earlier this year we released a Kubernetes Gateway API implementation in our Kubernetes Operator. In this release we included support for some ngrok traffic policies using the existing route filters like requestHeaderModifier
or urlRewrite
. We also launched our Traffic Policy Module that simplifies managing traffic to your applications and APIs.
We are now excited to announce support for ALL traffic policy actions with the Gateway API using our new Policy CRD.
All traffic policies in one CRD
ngrok traffic policies are the latest and greatest way to shape your traffic. We built a new NgrokTrafficPolicy
CRD designed specifically to handle these traffic policies. This CRD is powered by ngrok’s traffic policy engine and accepts whole policies, so you can use existing policies that you have built and validated with minimal effort. Policies can be as simple or complex as you want and are easy to create. The below is an example of an NgrokTrafficPolicy
resource that returns a custom response when someone accesses a specific path using GET:
These policy resources can be used in multiple places if you have multiple ingresses or routes that need the same policy, just like our existing NgrokModuleSets
.
Extend the Kubernetes Gateway API
One of the advantages of the Gateway API is that the spec has built-in extension points so that implementers, like ngrok, could use their unique capabilities within the spec without having to resort to annotations. Using annotations was essentially a “hack” to enable resources like Kubernetes Ingress to be configured outside the built in spec which was harder to understand and manage. The extension capabilities in the Gateway API allow configuration in the same places where the rest of the configuration for a resource lives. This capability is exposed through a filter called extensionRef
. Below is an example of a simple policy and an HTTPRoute
that uses that policy:
The policy above denies any request where the request type is PATCH
. The route defines 4 major components:
hostnames
: Which means that any traffic sent topolicy-test.ngrok.app
will be handled by this routematches
: Which states that any traffic being sent to the root path (/) will be included in the rulesfilters
: Which include theextensionRef
to the previously created policy, applying it to all traffic hittingpolicy-test.ngrok.app/
backendRefs
: Which says if the traffic topolicy-test.ngrok.app/
makes it through the policy (i.e. it is a method other thanPATCH
), it will be sent to the servicemy-service
on port 443
Simple, yet powerful
Using the NgrokTrafficPolicy
with the Gateway API gives you incredible power and flexibility. This resource can use any of the policy actions we support, ranging from denying specific IPs to JWT validation, and the list continues to grow! These policies also give you the ability to create more sophisticated expressions for managing and shaping your traffic.
What about modules and the ingress controller?
If you are using the ingress controller, NgrokTrafficPolicy
s will work with that as well! You can attach NgrokTrafficPolicy
objects to ingress objects in the same way you would with module-based CRDs. However, you cannot use both NgrokTrafficPolicy
and modules on a given ingress object. If you want to learn more about using the Policy CRD with ingress, check out our docs. ngrok modules have not been compatible with Gateway API and we have no plans to add that support in the future.
Get started today
Trying out policy with the NgrokTrafficPolicy
CRD is just two steps: First, create a policy following the guide in our docs. Then, follow the instructions in our new Kubernetes Operator User Guide to attach this policy to an HTTPRoute
our Ingress
object.
Sign up, try it out, and send us feedback! You can reach us on ngrok community on GitHub or at support@ngrok.com. We’d also love to hear from you if you have an idea/request for an action.