Replicate proxy_redirect reverse proxy option

[bozho]

Hi all,

I'm pretty sure this is possible, but being still new with k8s and gateway API (I'm playing with Nginx Gateway Fabric).

We have backend services and we want to use reverse proxy to expose them on a path (e.g. the API service on http://www.example.com/api/ ). In order to properly set the response Location and Refresh headers, if we were configuring "regular" Nginx server, we'd have something like this in the configuration:

...
location /api/ {
...
    proxy_pass            $upstream$uri$is_args$args;
    proxy_redirect        / /api/;
...
}

My question is essentially: how do I replicate proxy_redirect when using Gateway API?

[kate-osborn]

Hi @bozho. Thanks for opening this discussion and trying out NGINX Gateway Fabric!

Ok, so I've done some testing locally and have come up with a couple options for you.

First up, here's a very basic example of how you can expose the path /api/ for the hostname www.example.com using Gateway API resources:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: "www.example.com"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-example
spec:
  parentRefs:
    - name: gateway
  hostnames:
    - "www.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix # or Exact depending on your use case
            value: /api/
      backendRefs:
        - name: my-api-backend
          port: 80

If the default behavior does not suite your needs, and you need to change the Location and Refresh response headers, you have a couple choices.

1. Use a ResponseHeaderModifier filter

You can set the Location and Refresh response headers by adding the ResponseHeaderModifier filter to your routing rule. This would change the HTTPRoute shown above to:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-example
spec:
  parentRefs:
    - name: gateway
  hostnames:
    - "www.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            set:
              - name: Location
                value: "/api/"
              - name: Refresh
                value: "/api/"
      backendRefs:
        - name: my-api-backend
          port: 80

However, this approach isn't very flexible because we don't currently support NGINX variables in the header values. So you can't do something like:

 responseHeaderModifier:
    set:
      - name: Location
        value: "http://$host:$server_port/"
      - name: Refresh
        value: "http://$host:$server_port/"

and you also can't specify the redirect parameter using this approach.

3. Use a custom NGINX Gateway Fabric filter called SnippetsFilter

SnippetsFilters are a new feature that will be released in 1.5, which is scheduled to be released tomorrow.

SnippetsFilters are a custom filter that allow you to inject NGINX configuration into various contexts in NGINX. Here's what this would look like for your use case:

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
  name: proxy-redirect
spec:
  snippets:
    - context: http.server.location
      value: proxy_redirect / /api/;
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-example
spec:
  parentRefs:
    - name: gateway
  hostnames:
    - "www.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/
      filters:
        - type: ExtensionRef
          extensionRef:
            group: gateway.nginx.org
            kind: SnippetsFilter
            name: proxy-redirect
      backendRefs:
        - name: my-api-backend
          port: 80

If you want to try out SnippetsFilters today (before they are released tomorrow), you can deploy the edge or main version of NGINX Gateway Fabric. You'll also need to enable SnippetsFilters as they are disabled by default. Here's more info on them: https://github.com/nginxinc/nginx-gateway-fabric/blob/main/site/content/how-to/traffic-management/snippets.md.

Hope this helps, and let us know if you run into issues with either approach.

[bozho]

Happy to help!

When it comes to hardening our sites, we try to follow best practices (OWASP, Mozilla), keep auditors happy and not break any of our clients' integrations :-)

We explicitly set TLS options (ssl_protocols, ssl_prefer_server_ciphers and ssl_ciphers). We remove server-identifying headers (server_tokens off; and more_clear_headers Server;), which NGF can do now. However, server_token off also removes nginx version from its error pages.

We also add a few headers for the proxied requests using proxy_set_header. My understanding is that this is done using RequestHeaderModifier in Gateway API, but some of the values are set using nginx variables, e.g. proxy_set_header X-Real-IP $remote_addr;.

[kate-osborn]

@bozho the 1.5 release is out if you want to give SnippetsFilters a shot: https://github.com/nginxinc/nginx-gateway-fabric/blob/main/CHANGELOG.md#release-150.

Thanks for the info on nginx directives you use, it's very helpful!

We also add a few headers for the proxied requests using proxy_set_header. My understanding is that this is done using RequestHeaderModifier in Gateway API, but some of the values are set using nginx variables, e.g. proxy_set_header X-Real-IP $remote_addr;.

Yes, this is correct. In the latest release, NGF does set the X-Real-IP header to $remote_addr, but if you want to use nginx variables in other header values, we will need to add support for that. There's an open issue for this work. Feel free to upvote it if it's something you're interested in. That will help us prioritize it.

[bozho]

Thank you, @kate-osborn, I'll give it a go, hopefully this week.

There are two more things that I don't see covered natively by the Gateway API: basic auth and IP blocking.

Our scenario in this case is that we have a multi-tenant service (i.e. each client has separate instances of the service). Once live, service instances are usually public, but during implementation we fence them off using basic auth and/or IP blocking.

I see that some implementations, like Envoyproxy use SecurityPolicy resources to support basic auth, ip blocking and CORS. Are these things on your roadmap?

[kate-osborn]

Bringing our product manager @mpstefan into the conversation to answer your questions about roadmap.

For what it's worth, you can implement IP blocking now with SnippetsFilters. However, basic auth with SnippetsFilters would be trickier since it requires a file for the user/pass info. Should work if you mount the user/pass file to the nginx container.

[mpstefan]

IP Blocking isn't on our immediate roadmap, but fortunately looks easy to implement with Snippets. In terms of auth, we're actually watching the Gateway API for an upcoming GEP on including auth as part of the spec - in which case we'd want to implement auth the Gateway API way instead of our own Policy. Same deal with CORS, and we'll see how the spec shakes that feature out.

In any case, we'll take a look at basic auth at the same time we are looking at JWT in 2025. You can always see the current roadmap from here as well: https://github.com/orgs/nginxinc/projects/14/views/31

Thanks for taking the time to write this down! This kind of feedback is super helpful!