Repository: kubernetes-sigs/gateway-api

Issue #634: Request Filtering Between Gateways and Namespaced Routes
Created: 2021-04-27T21:17:55Z
What would you like to be added:
A method for Gateway administrators to use routing rules to filter which traffic can be forwarded to downstream routes.
As a Gateway administrator managing an HTTP load balancer I would like to delegate particular path prefixes to namespaced HTTPRoutes to prevent namespace administrators from writing rules that conflict with the rules from other namespaces.
For example, I should be able to delegate /cats to the cats namespace and /dogs to the dogs namespace. Then the administrators for each of those namespaces can safely write any rule they want, but with the expectation that the path
rules are prefixed with /cats or /dogs. /cats/food and /dogs/food would never collide  because the Gateway administrator had already pre-filtered the traffic.
Why is this needed:
Currently the API allows request filtering for HTTPRoutes and TCPRoutes. Gateway administrators can delegate traffic routing down to those routes which should be owned by individual namespace administrators (Think Hub and Spoke).
This immediately raises the issue of how can a central administrator prevent multiple namespaces from writing conflicting routing rules. Current documentation states that if namespace A and namespace B create the same routes the conflict will be resolved via timestamp (HTTPRouteRule).

Duplicate issue #582: Allow cross namespace references
Created: 2021-03-11T21:16:07Z
What would you like to be added:
Cross namespaces references in Route and BackendPolicy.
Examples:
A gateway may want to expose a route for a service in another namespace. For example, maybe we set up a dedicated gateway namespace a define a few routes to expose Services in other namespaces. This may sound like a security issue (a user can expose my secret Service externally without my permission), but it isn't inherently so - a user could already do this by manually configuring the proxy. If the user actually wants to restrict traffic from other namespaces, like our gateway namespace here, they need to do that in NetworkPolicy or similar, not assume someone won't proxy external traffic to their service:
apiVersion: networking.x-k8s.io/v1alpha1
kind: BackendPolicy
metadata:
  name: policy
  namespace: gateway
spec:
  backendRefs:
  - name: foo
    kind: service
    namespace: bar # NEW: cross namespace reference
    port: 80
---
apiVersion: networking.x-k8s.io/v1alpha1
kind: HTTPRoute
metadata:
  name: foo-route
  namespace: gateway
spec:
  hostnames:
  - foo.example.com
  rules:
  - forwardTo:
    - serviceName: foo
      namespace: bar
      port: 80
A user may migrate to a new namespace and need to do a traffic split
apiVersion: networking.x-k8s.io/v1alpha1
kind: HTTPRoute
metadata:
  name: foo-route
  namespace: gateway
spec:
  hostnames:
  - foo.example.com
  rules:
  - forwardTo:
    - serviceName: foo
      namespace: bar
      port: 80
      weight: 2
    - serviceName: foo-new
      namespace: bar-new
      port: 80
      weight: 1

Closing comment (2021-05-13T18:26:21Z): Thanks for the great feedback here @banks! I think your example of centrally managed Gateway + Routing is going to be fairly common.

Currently the NetOps team would need RBAC permissions to create HTTPRoutes in each service namespace to setup the prefix forwarding. They'd then need to use RBAC rules or likely a custom admission controller policy to prevent the application teams from modifying those and affecting the prefix their service is exposed at or interfering with other team's prefixes etc.

This is closely related to #634 which would enable further Routing in the target namespace through Route delegation. Interested in your feedback on that approach as well.

Is the suggestion that ExternalName is already a workaround so we don't need another way, or that since ExternalName workaround already exists, the API might as well provide the equivalent with a better UX for this use-case?

Yeah, this was pretty confusing. I was trying to say that since it's already possible, we might as well make it obvious that it's possible instead of hiding the functionality. And if that's our goal, it probably makes the most sense just to add a namespace ref to the forwardTo instead of requiring users to use the ExternalName workaround.
This is really top of mind for us over the next couple weeks. This will actually be our main topic for our next community meeting.