kgateway-dev/kgateway

kgateway version v2.4.0-main Kubernetes Version v1.35.5 Describe the bug The kgateway.dev/signature-algorithms listener TLS option (#14281) is comma-split without validating algorithm names or dropping empty entries (ApplySignatureAlgorithms in pkg/kgateway/translator/sslutils/ssl_utils.go), so a typo (rsa_pss_rsae_sha255) or a trailing comma (rsa_pss_rsae_sha256,) reaches Envoy and is NACKed: gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) listener~8443: Failed to initialize TLS signature algorithms bogus_alg Three consequences, all verified live on v2.4.0-main: The listener condition still reports Programmed=True while the data plane rejected it. A brand-new listener never comes up: the Service exposes the port, all Gateway status conditions are healthy (Accepted=True / ResolvedRefs=True / Programmed=True), but Envoy never creates the listener — connections are refused (curl exit 7). On an existing working listener

kgateway version v2.2.0 (also missing in v2.3.0-rc.2 as of writing) Is your feature request related to a problem? Please describe. ListenerPolicy.spec.default currently exposes access logging only under httpSettings.accessLog, which translates to Envoy's HTTP Connection Manager. There is no equivalent field for listeners that terminate or pass through non-HTTP traffic, so connections served by TCPRoute or TLSRoute on the same Gateway cannot be access-logged at all. This breaks observability parity for Gateways that serve a mix of protocols. A Gateway that terminates HTTPS for HTTPRoutes and forwards plain TCP (or terminates TLS) for L4 workloads via TCPRoute / TLSRoute on distinct ports gets full per-request logs for the HTTP path and zero per-connection visibility on the L4 path — no client address, no SNI for TLS, no byte counts, no connection duration, no response flags. That makes capacity work, incident response, and per-tenant attribution impossible for the TCP path. We verifie

kgateway version v2.2 Is your feature request related to a problem? Please describe. There have been quite a few times where a desired feature or configuration is not supported by kgateway, but is supported by envoy. In our other Envoy based system (Istio, which we use for our service mesh), we have the ability to apply patches directly into the config using their EnvoyFilter resource. Describe the solution you'd like It would be great if there was a resource, similar to Istios EnvoyFilter or Envoy Gateways EnvoyPatchPolicy to allow the more adventurous amongst us to more directly control envoy when the abstraction doesn't quite do what we need. Describe alternatives you've considered No response Additional Context Whilst I think on balance this would be a good feature, and give users a break glass mechanism when faced with something that the need that is not (yet) supported natively, there are risks/downsides too, e.g. security implications for misconfiguration.

kgateway version v2.2.0 Kubernetes Version 1.34.5 Describe the bug Using TrafficPolicy's buffer.maxRequestSize to restrict the maximum allowed size of requests functionally works, however it does so by adding an Envoy Buffer to the relevant filter chains, which results in all request payloads to fully buffer in memory before being sent to the client. In the cases where clients send large payloads, this results in excessive memory usage on the kgateway pods that can easily result in OOM's. Ideally it should be possible to restrict the max request size, without forcing requests to be fully buffered. If in practicality this is not possible with Envoy, potentially an option to enable file system buffering (https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/file_system_buffer_filter) would be appropriate, to take the memory pressure off kgateway. Related: #13641 Expected Behavior When using maxRequestSize, large client payloads should be safe from bringing down kgat

Create a GH workflow that syncs issues from this repo labeled with kind/ingress-nginx to the kgateway-dev/ingress2gateway repo. This will help ensure we continue supporting automated ingress-nginx migrations after the feature has been implemented.