Cross Namespace Routing

This article explains cross-namespace routing for the Kubernetes Gateway API and how to enable it for the NGINX Gateway Fabric. In many production clusters, Gateways are deployed into a central infrastructure namespace while application teams operate in separate namespaces. By default, Gateway API implementations restrict routing to the Gateway’s own namespace — you must explicitly opt into cross-namespace routing.

A diagram titled "In Namespace Routing" showing a gateway successfully routing to an App in Namespace A (green check) while a route to an App in Namespace B is blocked (red cross and "Not Allowed"). The caption states the gateway cannot accept routes from different namespaces.

Why this matters

Platform teams often centralize infra components (Gateways, GitOps controllers, policy engines) in a dedicated infra namespace.
Application teams deploy services and routing objects into team-specific namespaces to isolate quotas, limits, and permissions.
If cross-namespace routing is not enabled, a central Gateway cannot accept route objects from other namespaces, preventing teams from exposing their applications through the shared Gateway.

Common cluster layout

Namespace infra: Gateways, Argo CD controllers, Kyverno, shared platform resources.
Namespace team-a, team-b, etc.: Application deployments, Services, Route objects (HTTPRoute, TCPRoute).

How to enable cross-namespace routing You control cross-namespace routing through the Gateway’s allowedRoutes field. There are two primary approaches:

Allow routes from all namespaces (broad, less restrictive).
Allow routes only from namespaces that match a label selector (recommended, follows principle of least privilege).

Example: Allow routes from any namespace

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: infra
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: "*.example.com"
  allowedRoutes:
    namespaces:
      from: All

Example: Restrict routes to namespaces that match a label selector (recommended)

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: infra
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: "*.example.com"
  allowedRoutes:
    namespaces:
      from: Selector
      selector:
        matchLabels:
          team: frontend

Use the principle of least privilege: prefer a label selector (Selector) to limit which namespaces can reference the Gateway. Use All only when you have a clear, audited reason to permit routes from every namespace.

AllowedRoutes quick comparison

Option	Description	Example / Notes
`All`	Gateway accepts routes from any namespace	`allowedRoutes.namespaces.from: All` — broad access; simpler but less secure
`Selector`	Only namespaces that match the label selector can reference the Gateway	`allowedRoutes.namespaces.from: Selector` with `selector.matchLabels` — recommended for least privilege

Referencing the Gateway from another namespace When a Route object (for example, an HTTPRoute) lives in a different namespace than the Gateway, it must explicitly include the Gateway’s namespace in its parentRefs. If you omit the namespace field, the API assumes the parent resides in the same namespace as the Route. Example HTTPRoute in namespace team-a referencing the gateway in namespace infra:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: team-a-route
  namespace: team-a
spec:
  parentRefs:
    - name: gateway
      namespace: infra
  hostnames:
    - "app.team-a.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: "/"
      backendRefs:
        - name: app-service
          port: 80

Best practices checklist

Set allowedRoutes.namespaces.from to Selector whenever possible and use selector.matchLabels to limit which namespaces can attach routes to the Gateway.
Ensure each route’s parentRefs[].namespace is set to the Gateway’s namespace when routes live outside the Gateway’s namespace.
Apply namespace labels (for example, team: frontend) consistently to enable selector-based access control.
Audit your Gateways and Route objects periodically to confirm only intended namespaces are allowed.

Relevant links and references

Gateway API overview: https://gateway-api.sigs.k8s.io/
Kubernetes Gateway API docs: https://kubernetes.io/docs/concepts/services-networking/gateway/
NGINX Gateway Fabric docs: https://docs.nginx.com/nginx-adap/ (refer to your NGINX provider documentation for Fabric-specific behavior)

A presentation slide titled "Cross Namespace Routing" with two blue panels: "Recommended: Principle of Least Privilege" and "Caution: Broad Permissions." The left panel lists safe practices (only allow what you need, avoid deployment errors, use specific labels) while the right warns against enabling gateways or broad permissions across all namespaces.

Summary Enabling cross-namespace routing with the Gateway API and NGINX Gateway Fabric allows a centralized Gateway to accept routes defined by application teams in their own namespaces. For secure, manageable access, prefer selector-based allowedRoutes and always include the Gateway namespace in parentRefs for cross-namespace routes.

Introduction & Why Gateway API

Core Gateway API Resources

Advanced Traffic Management

TLS and Cross-Namespace Security

Troubleshooting and Best Practices

Cross Namespace Routing

Watch Video