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]

Hi @kate-osborn, thank you for the reply!

The last option looks really interesting, I'll give it a go when you've released it, especially since I suspect we'll want to tweak more nginx options for production.

[kate-osborn]

Sounds good! We would also love to hear which nginx directives you are interested in using for production. That will help us figure out which directives to expose in first-class API fields, so you don't have to use SnippetsFilters for everything 🙂

[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.