Route KAS workspaces through a dedicated plain Service

What does this MR do?

The KAS workspaces server listens on plain HTTP, also with global.kas.tls.enabled, but all workspaces routes went to the main KAS Service. Depending on the Ingress or Gateway provider, workspaces were therefore unreachable or received TLS. This MR gives the workspaces routes a plain Service of their own, and separate routes on the KAS host.

Overview

Fix	Providers	Impact on master	Introduced in	Fixed in	Validation
Dedicated <release>-kas-workspaces Service, rendered with global.workspaces.enabled	All	Workspaces routes target a port the main KAS Service does not expose, so workspaces are unreachable (Envoy 500/404, Traefik 415/404, NGINX 503)	b71965c3	1ec3793c, a8fefe19 (KAS host path)	kind: 307 from the workspaces server on all three; specs
Workspaces Service stays plain HTTP: Traefik http scheme, not covered by the KAS BackendTLSPolicy	Traefik, Gateway API	Latent: with KAS TLS, the workspaces server receives TLS	Gateway API: ead6dcdd, Traefik: !5448 (merged)	1ec3793c, a8fefe19 (KAS host path)	kind with KAS TLS; specs
Workspaces HTTPRoute uses the kas-workspaces-web listener	Gateway API	Wildcard workspaces route rejected (NoMatchingListenerHostname)	696c4a3e	1ec3793c	kind (Envoy): 404 to 307; specs; all other routes render the same parentRefs
Wildcard workspaces HTTPRoute matches /, like the wildcard Ingress	Gateway API	Latent behind the rejected route: workspace hosts answer 404 outside /workspaces	696c4a3e	88c8cac1	kind (Envoy): 404 to 307 on /; specs; found by the new k3d review spec
KAS host /workspaces in its own <release>-kas-workspaces-api HTTPRoute	Gateway API	Latent: BackendTrafficPolicy forces h2c onto the HTTP/1.1 server (502 for HTTP/2 clients)	b85616b6	a8fefe19	kind (Envoy): 307 for HTTP/1.1 and HTTP/2; specs
KAS host /workspaces in its own <release>-kas-workspaces-api Ingress	NGINX	Latent: KAS Ingress backend TLS annotations apply to the workspaces path	b71965c3	26b38982	kind (NGINX, KAS TLS): 307; specs

Latent: hidden on master by an earlier issue in the table, mostly the missing workspaces port, which the main KAS Service only exposes with the undocumented gitlab.kas.workspaces.enabled.

Validated on a local kind cluster with KAS TLS from an internal CA, deploying master and this branch with Envoy Gateway 1.9.2, Traefik v3.7.13 and the bundled NGINX Ingress. gRPC (grpc-status: 16) and the Kubernetes API proxy (401) worked in all runs.

CI now covers workspaces connectivity: the k3d review specs (spec/features/kas_workspaces_spec.rb, 6294dd84) expect the workspaces server's OAuth redirect on the KAS host and on a wildcard workspaces host through Envoy Gateway and Traefik over HTTPS and NGINX over HTTP, which catches the missing port, the wrong listener and the wildcard path match, but not the latent KAS TLS issues, because CI does not enable global.kas.tls.

Notes

• Like the gRPC Ingress, the <release>-kas-workspaces-api Ingress shares the KAS TLS Secret without cert-manager annotations of its own. The HTTPRoute is separate for the same reason as the Kubernetes API proxy route (#6557 (closed)).
• The new gitlab.gatewayApi.gatewayRef.section helper lets the workspaces HTTPRoute reference its own listener.
• The Gateway API docs no longer warn against using Workspaces with internal TLS for KAS.

Raised in the review of !5448 (merged) and split out of it.

Related issues

Related to !5448 (merged)

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.
• When ready for review, MR is marked as ready (not a draft) and assigned to a reviewer.

Reviewers checklist

• As soon as you begin reviewing, select Start a review on your first comment so the MR shows Reviewer started review.
• MR has a green pipeline on https://gitlab.com/gitlab-org/charts/gitlab.
• Consider downstream impact to the Operator, as per evaluating impact from changes to GitLab chart.