Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected Cross-Namespace Route Acceptance and Listener Name Anomaly in Gateway Configuration #2036

Open
steveliem opened this issue Feb 28, 2024 · 1 comment
Labels
enhancement New feature or request Type/Improvement

Comments

@steveliem
Copy link

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.

Suggested Labels:
bug, gateway-api, cross-namespace-routing, apk, listener-configuration

Affected Product Version:

  • Helm chart version: apk-helm-1.0.0
  • WSO2 APK version: 1.16.0

OS, DB, other environment details and versions:

  • Kubernetes version: v1.28

Steps to reproduce:

  1. Deploy WSO2 APK using the Helm chart with the default Gateway setup.
  2. Confirm the Gateway is configured to accept routes only from the same namespace.
  3. Create an HTTPRoute in a different namespace (wso2demo) with parentRefs 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.
  4. Invoke an API that matches the HTTPRoute conditions using a valid token.
  5. Observe that the API call is unexpectedly allowed through, despite the cross-namespace reference and non-existent listener name.

Related Issues:
N/A

Additional Context:
Gateway configuration snippet from the apk namespace, highlighting the expected namespace restriction:

# Gateway configuration snippet
...
spec:
  gatewayClassName: default
  listeners:
    - name: gatewaylistener
      allowedRoutes:
        namespaces:
          from: Same
...

HTTPRoute configuration snippet from the wso2demo namespace, showing the reference to a non-existent listener, yet still functioning:

# HTTPRoute configuration snippet
...
metadata:
  namespace: wso2demo
spec:
  parentRefs:
    - name: default
      namespace: apk
      sectionName: httpslistener  # Non-existent listener name
...

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.

@CrowleyRajapakse
Copy link
Contributor

Hi @steveliem ,

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.

Thanks,
Sampath

@CrowleyRajapakse CrowleyRajapakse added the enhancement New feature or request label Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Type/Improvement
Projects
None yet
Development

No branches or pull requests

2 participants