fix: disable Envoy Gateway request timeouts for webservice

Clemens Beckrequested to merge
cb/disable-webservice-timeouts into master

What does this MR do?

The gateway route applied a 15s request/backendRequest timeout to all webservice traffic, with a separate long-running rule exempting only git SSH/HTTP operations. This broke legitimate operations that routinely exceed 15s, such as large file downloads or websocket traffic.

This MR fixes that in two parts:

  1. Remove the absolute HTTPRoute timeouts (fix: disable Envoy Gateway request timeouts for webservice): collapse the two rules into a single root rule with 0s (disabled) HTTPRoute timeouts. NGINX Ingress never applied an absolute request deadline, so this restores the previous behavior. The default can be overridden per webservice deployment via gitlab.webservice.deployments.<name>.gatewayRoute.rules.

  2. Add sane inactivity-based upstream timeout defaults (Add upstream timeout defaults via BackendTrafficPolicy): a new BackendTrafficPolicy targeting the webservice HTTPRoute ships:

    • timeout.tcp.connectTimeout: 300s — caps upstream connection establishment (equivalent to NGINX proxy-connect-timeout).
    • timeout.http.streamIdleTimeout: 3600s — caps stream inactivity (closest equivalent to NGINX proxy-read-timeout). It resets while data flows in either direction, so long-running downloads, uploads, and websockets keep working while idle streams are reclaimed.

    The policy spec is overridable wholesale via gitlab.webservice.backendTrafficPolicy.spec (with targetRefs injected when omitted, following the pattern from !5183 (merged)), and spec: null skips rendering it.

Where the default values come from

The BackendTrafficPolicy defaults (connectTimeout: 300s, streamIdleTimeout: 3600s) intentionally match what GitLab.com currently configures for the equivalent NGINX Ingress settings on webservice traffic (proxy-connect-timeout: 300, proxy-read-timeout: 3600 in gl-infra/k8s-workloads/gitlab-com). GitLab.com is the largest known-good reference deployment, and part of the goal of this work is getting the chart ready for GitLab.com adoption. The chart docs deliberately do not mention this provenance, because GitLab.com values may change independently of chart defaults.

Why no client-side timeout defaults

GitLab.com's NGINX layer does not configure client-side timeouts or connection limits — client/slow-client (Slowloris-style) protection is handled at its edge (Cloudflare), with NGINX built-in defaults and Rack::Attack behind it. To keep parity with that reference setup, this MR only introduces the backend-side defaults needed for backwards compatibility with the previous NGINX Ingress behavior, and does not set client-side defaults such as ClientTrafficPolicy spec.timeout.http.requestReceivedTimeout (which could interrupt legitimate slow uploads). Instead, the webservice chart docs now document how to harden the client side (requestReceivedTimeout, spec.connection limits) for deployments without an edge proxy or WAF in front of the Gateway.

Out of scope

  • Git over SSH: rides the gitlab-shell TCPRoute, governed by Envoy's TCP idle timeout default (1h) — more permissive than the previous NGINX stream passthrough default (proxy-stream-timeout: 600s), so there is no regression. Explicit configuration surface for it can be a follow-up.
  • Registry: has its own HTTPRoute and NGINX-era timeout defaults (proxyReadTimeout: 900) that may deserve the same treatment as a follow-up.

Addresses the AppSec/InfraSec guidance in https://gitlab.com/gitlab-org/charts/gitlab/-/work_items/6563 (finite, configurable defaults; documented hardening).

Changelog: fixed

Closes #6575 (closed)

Related issues

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
  • Tests added/updated.
  • Have you validated that your change works end-to-end on a real cluster deployment?
    • Describe how you did it in a comment.
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by João Alexandre Cunha

Merge request reports