Define Default Gateway/Route Association Behavior

[danehans]

What would you like to be added:
Document gateway/route association. Should the default approach be open or closed?

Why is this needed:
Define the route field of the gateway resource. Should routes a) be associated to a gateway by default and use gateway.spec.routes as a filtering mechanism (default open) or b) not be associated to a gateway unless specified by gateway.spec.routes (default closed)? Default open provides ease-of-use, but may cause inadvertent route association. Default closed is more secure but requires additional coordination between cluster operator and developers.

/cc @bowei @jpeach @ironcladlou @Miciah

xref: #71

[Miciah]

This question is closely related to #12 (using label selectors to associate routes with gateways). Label selectors feel natural and appropriate but may be incompatible with extremely fine-grained, explicit access control (how do you restrict who can apply a label to a resource?).

[bowei]

I think we need both really.

Union type of explicit reference OR selector.
Gateway admin who wants to keep control will only use explicit references.
Gateway admin who wants to let their users chose can add a selector.

The real phase transition in complexity is to allow for some sort of selection at all.
My feeling right now is, let's pull it in and work with it to see what the consequences are.

[jpeach]

Should routes a) be associated to a gateway by default and use gateway.spec.routes as a filtering mechanism (default open)

If there are multiple gateways, how would you know which routes go with which gateway?

b) not be associated to a gateway unless specified by gateway.spec.routes (default closed)?

Hugely +1 on this. Association with a gateway could mean getting traffic from the internets or getting a service provider bill.

[Miciah]

If there are multiple gateways, how would you know which routes go with which gateway?

The route's status indicates with which gateways it is associated.

Association with a gateway could mean getting traffic from the internets or getting a service provider bill.

That is an interesting point. Does the API need a way to specify quotas? Which persona should be limits? Could this fall under traffic splitting or route rules? This seems like a new use-case.

[jpeach]

If there are multiple gateways, how would you know which routes go with which gateway?

The route's status indicates with which gateways it is associated.

But how do you know which gateway it should go with? Would all gateways just pick up all routes? If a route was already bound to gateway A, should gateway B pick it up implicitly?

Does the API need a way to specify quotas? Which persona should be limits? Could this fall under traffic splitting or route rules? This seems like a new use-case.

No, I don't think so. That's what GatewayClass is for. GatewayClass can mean "the internet-facing one", "the expensive one with guaranteed capacity", or whatever is needed.

[bowei]

I think general take is that Gateways should not pick up routes unless it was explicitly configured it to do so to avoid wide open defaults.

Also, need to note that there are several levels of ACLs here:

• ones applied to the controller service account.
• ones implemented inside the controller, subject to conformance testing.

[bowei]

/close

This is now documented in the route selection behavior in the code. It may still change due to discussion, but is now explicitly specified:
https://github.com/kubernetes-sigs/service-apis/blob/master/api/v1alpha1/gateway_types.go

[k8s-ci-robot]

@bowei: Closing this issue.

In response to this:

/close

This is now documented in the route selection behavior in the code. It may still change due to discussion, but is now explicitly specified:
https://github.com/kubernetes-sigs/service-apis/blob/master/api/v1alpha1/gateway_types.go

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.