You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
Using the WSO2 APK Helm chart (apk-helm-1.0.0), a potential bug related to cross-namespace route acceptance has been observed. The default Gateway configuration, deployed in the apk namespace, includes allowedRoutes.namespaces.from: Same, implying that only routes from the apk namespace should be accepted. Contrary to this configuration, an HTTPRoute from the wso2demo namespace is successfully processed by the Gateway. Additionally, the HTTPRoute references a non-existent listener name in the parentRefs configuration, yet the traffic still passes through, which is unexpected and suggests an inconsistency in the Gateway's behavior.
I would expect the API to work only if the Gateway configuration allowed cross-namespace routes with from: All and if the HTTPRoute specified a valid listener name present in the Gateway configuration.
This behavior is not aligned with the Gateway API specifications and our understanding of the intended restrictions on cross-namespace routing and listener name matching. It indicates a potential bug in the gateway implementation that requires investigation and resolution.
The text was updated successfully, but these errors were encountered:
Here, the httpslistener is the envoy listener(it's not related to defined gateway listeners) which we have defined as the one and only listener in the envoy config and the Gateway Listeners are added as Filter Chain Matches in envoy(not as a listener).
Here, the only validation which we are currently doing when reconciling HTTPRoutes is the HTTPRoute parentRef having a the correct gateway name(default) and namespace. We don't validate sectionName since we only have one hardcoded listener defined in Envoy, which is the section name.
Also we haven't added any validation or implementation with regards to allowedRoutes configuration in gateway CR. We are planning on improving the implementation to support unimplemented Gateway API Specification capabilities.
Description:
Using the WSO2 APK Helm chart (apk-helm-1.0.0), a potential bug related to cross-namespace route acceptance has been observed. The default Gateway configuration, deployed in the
apk
namespace, includesallowedRoutes.namespaces.from: Same
, implying that only routes from theapk
namespace should be accepted. Contrary to this configuration, anHTTPRoute
from thewso2demo
namespace is successfully processed by the Gateway. Additionally, theHTTPRoute
references a non-existent listener name in theparentRefs
configuration, yet the traffic still passes through, which is unexpected and suggests an inconsistency in the Gateway's behavior.Suggested Labels:
bug, gateway-api, cross-namespace-routing, apk, listener-configuration
Affected Product Version:
OS, DB, other environment details and versions:
Steps to reproduce:
HTTPRoute
in a different namespace (wso2demo
) withparentRefs
pointing to a listener (httpslistener
) that doesn't match any listener name in the actual Gateway configuration, using the artifacts given in Cross-Namespace API Routing Fails with 404 Error in Multi-Namespace Configuration #2021.HTTPRoute
conditions using a valid token.Related Issues:
N/A
Additional Context:
Gateway configuration snippet from the
apk
namespace, highlighting the expected namespace restriction:HTTPRoute configuration snippet from the
wso2demo
namespace, showing the reference to a non-existent listener, yet still functioning:I would expect the API to work only if the Gateway configuration allowed cross-namespace routes with
from: All
and if theHTTPRoute
specified a valid listener name present in the Gateway configuration.This behavior is not aligned with the Gateway API specifications and our understanding of the intended restrictions on cross-namespace routing and listener name matching. It indicates a potential bug in the gateway implementation that requires investigation and resolution.
The text was updated successfully, but these errors were encountered: