Skip to content

No hairpin path for hostnames published through the Gateway API: in-cluster clients cannot reach their own published URL #3821

Open

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.proxyProtocol is 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.target at the host ingress-nginx Service;
  • controller.gatewayApi stays 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

  1. added
    kind/featureCategorizes issue or PR as related to a new feature
    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)
    on Aug 14, 2026
  2. added
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)kind/featureCategorizes issue or PR as related to a new featurepriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to completetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions