security: cross-namespace Service backends lack target-owner consent and leak an existence oracle

[dcmcand]

Summary

spec.service.namespace lets a NebariApp reference a Service in another namespace, and the operator generates a cross-namespace backend reference without requiring proof that the target Service owner consented. The validation path also reports whether a named Service and port exist, which discloses that information across namespaces.

Affected code

• api/v1/nebariapp_types.go (L79-85) - the optional Namespace field is documented as allowing references to Services in other namespaces.
• config/rbac/role.yaml (L3 ClusterRole; L14-22) - the operator has cluster-wide get/list/watch on services.
• internal/controller/reconcilers/core/reconciler.go - ValidateService (L120-155) resolves the target namespace (L124-127), gets the Service (L134), and validates the port (L143-154). It returns distinct messages for a missing Service (L136) versus a missing port (L152), surfaced via the Ready condition and a Warning event (L65-72).
• internal/controller/reconcilers/routing/httproute.go - buildBackendRefs (L271-286) sets backendRef.Namespace when the Service namespace differs from the app namespace. No ReferenceGrant is created or checked anywhere in the operator.

Note: Gateway API itself requires a ReferenceGrant in the target namespace for the cross-namespace backend to receive traffic, which is a target-side control. The gap here is that the operator performs no consent check of its own, and the validation path leaks a Service existence/port oracle before any such enforcement.

Impact

Broad ReferenceGrant configuration combined with cluster-wide Service validation can turn this into cross-tenant publication, and the validation responses can be used to probe for Service and port existence in other namespaces.

Remediation

• Default to same-namespace backends.
• Require an explicit target-owner authorization object naming the source namespace, NebariApp, Service, and port; reject broad grants in production policy.
• Avoid using privileged validation as a cross-namespace Service oracle (for example, do not distinguish "not found" from "port missing" in cross-namespace responses).
• Record target consent in status.

Acceptance criteria

• Cross-namespace Services require explicit target-owner consent.
• Validation does not disclose cross-namespace Service/port existence to unauthorized callers.

References

• CWE-284 (Improper Access Control)

Line numbers reference commit 4ad2c10.