Repository navigation
Description
In-cluster workloads cannot reach a hostname published through the Gateway API, and nothing in the platform bridges that today. Reported in the community chat by an operator moving from ingress-nginx to the Gateway: same URL, worked over Ingress, stopped working over the Gateway, which breaks any OIDC-style flow where the backend has to validate tokens against the same base URL the browser uses. https://t.me/cozystack/16789
Ouroboros is the piece that makes a published hostname resolvable from inside the cluster, and on the host it covers ingress-nginx only:
- it is emitted only when
publishing.proxyProtocolis true (packages/core/platform/templates/bundles/system.yaml), so a cluster that never turned PROXY protocol on has no hairpin path at all; - the same template points
proxy.targetat the host ingress-nginx Service; controller.gatewayApistays at the upstream default of false, so it does not watch Gateway API objects.
The comment in packages/system/ouroboros/values.yaml justifies that last point with "cozystack does NOT install Gateway-API CRDs cluster-wide on the host (system/gateway-api-crds is only registered in the kubernetes-application PackageSource — tenant scope)". That is no longer true: templates/bundles/system.yaml emits cozystack.gateway-api-crds among the common packages, so the CRDs are on the host and the stated blocker for --gateway-api is gone.
What needs deciding is whether the hairpin path becomes part of the Gateway publishing story, meaning ouroboros watches Gateway routes and stops being tied to publishing.proxyProtocol, or whether we document that in-cluster clients must address services internally. The Keycloak case that surfaced this is already handled the second way, #3289 defaults keycloakInternalUrl to the in-cluster Service, but that is one component, not an answer for tenant workloads that publish through the Gateway and then call themselves back.
Activity