Large Client Header Buffers

Projects NGINX Gateway Fabric
,
1

My issue:

We are currently moving from Ingress Nginx to Nginx Gateway Fabric. I am working on setting up the configuration, and I am wondering if there policies in the near future that will handle: large-client-header-buffers configuration?

requests headers might contain headers needing up to 8 32k for client header buffers.

How I encountered the problem:
Simply trying to map Ingress Nginx config to NGF proxy settings/policies

Solutions I’ve tried:

I know about the snippetsfilter, but I´d like to avoid that as much as possible.

Version of NGF and/or NGINX:

nginx-gateway-fabric:2.4.1

Deployment environment:
k8s

2

Hi @j88p , there are no plans as of yet to add this field to a policy, but if it’s a common enough field for our users, then we will certainly consider adding it. Out of curiosity, is this something you would want to apply globally or per Route?

Also if I may ask, can you explain your hesitation with using a Snippet?

3

Thank you @sjberman for your response!

I understand, and I am now using the SnippetsPolicy at gw level and SnippetsFilter at the HttpRoute level - I guess I was just hesitant due to the NGF documentation stating that it should be used with caution.

Can I ask a couple separate questions?

The Ingress Nginx OSS project is explicitly setting the proxy_set_header Proxy “”; - is this necessary in NGF? Our stack is .NET, Node and very little Golang. I´m assuming modern framworks handle this issue. But could it be used as a defense in depth approach regardless?

I´m using the SnippetsPolicy as follows:

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsPolicy
metadata:
name: custom-snippets
namespace: nginx-gateway-test
spec:
targetRefs:
    - group: gateway.networking.k8s.io
kind: Gateway
name: nginx-gateway
snippets:
    - context: http
value: |
        large_client_header_buffers 8 32k;
        proxy_connect_timeout 5s;
        proxy_set_header Proxy "";
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        proxy_next_upstream_tries 3;
        server_names_hash_max_size 4096;
        variables_hash_max_size 2048;

I´m also using the SnippetFilter to handle websocket connections

apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
name: websocket-timeouts
namespace: test 
spec:
snippets:
    - context: http.server.location
value: |
        proxy_read_timeout 3600s;                                 
        proxy_send_timeout 3600s;

Is it really so that proper sticky-sessions is paywalled behind Nginx Plus? It seems like websockets are such a standard approach to connectivity today, that it would be supported out of the box? We are using the ip_hash method instead since the tools we use websockets on currently are internal, but kind of limits our adoption of NGF as we would like to be able to at least be able to use websockets for external users as well, which could become an issue with shared IP and horizontal scaling operations.

4

The Ingress Nginx OSS project is explicitly setting the proxy_set_header Proxy “”; - is this necessary in NGF? Our stack is .NET, Node and very little Golang. I´m assuming modern framworks handle this issue. But could it be used as a defense in depth approach regardless?

As of right now we don’t see it as necessary. Our NGINX Ingress Controller doesn’t explicitly set this either. What concerns are there with this header?

Is it really so that proper sticky-sessions is paywalled behind Nginx Plus?

As of today, yes. However, NGINX OSS recently added support for sticky cookie sessions, so we will likely be adding support for it in our 2.6 release. We are waiting for the sessionPersistence API in HTTPRoutes to stabilize before we roll this out, because it is currently experimental and will likely be changing in Gateway API v1.6. So keep an eye out for this soon!

One other note, we’re looking at adding the various proxy_*_timeout fields to our ProxySettingsPolicy soon as well, so you won’t need a Snippet for those.

5

As of right now we don’t see it as necessary. Our NGINX Ingress Controller doesn’t explicitly set this either. What concerns are there with this header?

I was under the impression that this was related to a vulnerability some years back and just want to make sure I use the correct initial setup. Thank you!

We are waiting for the sessionPersistence API in HTTPRoutes to stabilize before we roll this out, because it is currently experimental and will likely be changing in Gateway API v1.6. So keep an eye out for this soon!

One other note, we’re looking at adding the various proxy_*_timeout fields to our ProxySettingsPolicy soon as well, so you won’t need a Snippet for those.

Ah, fantastic! Thank you for that information!

I appreciate your support, Have a great day!

Kindly,
Johan