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:

apiVersion: ngrok.k8s.ngrok.com/v1alpha1
kind: NgrokTrafficPolicy
metadata:
  name: example-greeting
  namespace: default
spec:
  policy:
    on_http_request:
      - expressions:
          - "req.method == 'GET'"
          - "req.path.startsWith('/greetings')"
        actions:
          - type: custom-response
            config:
              status_code: 200
              body: Hello
              headers:
                content-type: text/plain

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:

apiVersion: ngrok.k8s.ngrok.com/v1alpha1
kind: NgrokTrafficPolicy
metadata:
  name: traffic-policy-test
  namespace: default
spec:
  policy:
    on_http_request:
      - expressions:
          - "req.method == 'PATCH'"
        actions:
          - type: deny

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - kind: Gateway
      name: ngrok-gateway
  hostnames:
    - "policy-test.ngrok.app"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      filters:
        - type: ExtensionRef
          extensionRef:
            group: ngrok.k8s.ngrok.com
            kind: NgrokTrafficPolicy
            name: traffic-policy-test
      backendRefs:
        - name: my-service
          kind: Service
          port: 443

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 to policy-test.ngrok.app will be handled by this route
• matches: Which states that any traffic being sent to the root path (/) will be included in the rules
• filters: Which include the extensionRef to the previously created policy, applying it to all traffic hitting policy-test.ngrok.app/
• backendRefs: Which says if the traffic to policy-test.ngrok.app/ makes it through the policy (i.e. it is a method other than PATCH), it will be sent to the service my-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, NgrokTrafficPolicys 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.