Serving: Reference existing Gateway resource with the upcoming per-route Gateway splitting

[Joon-L]

In what area(s)?

/area networking

Describe the feature

With the feature request for referencing existing ingress Gateway resource in different namespace #5700 and upcoming support for per-Route Gateway #4312, users should be able to point Knative at an alternate existing istio Gateway resource for the per-Route Gateway.
This allows more fine-grained control over per-service ingress and enables support for certificate whitelisting via thumbprints, or mix/max protocol version for TLS which are possible through Istio Gateway objects but not directly configureable through Knative as of today.

@ZhiminXiang @tcnghia @rakelkar

[rakelkar]

Pre-created gateways per service is different from per service gateways created by knative. This is a more advanced ask (since normal knative users would not be expected to create gateways per service)... however as noted this enables auth configuration to be decoupled.

Alternative approaches would be:

1. Add support for all auth options to knative so it can create the appropriate per service gateway (e.g. client cert auth and AAD token auth etc).
2. or, Don't reconcile all fields of the gateway, so that a webhook can add auth options (this is kind of annoying though as all the auth config has to be passed to the webhook via annotations or some other lookup mechanism)

[ZhiminXiang]

I think we could support two ways of Gateway configuration:

1. Leverage Knative Certificate CRD as a standard API to configure Knative Ingress TLS. This is not Istio specific method, and should be automatically applied to other Knative Ingress solutions, such as gloo.
   Specifically, for Istio implementation, Knative fully controls and reconciles Gateway. Users should not be able to directly modify the Gateway.
   Note that we should only support the TLS options defined within Knative Ingress TLS, and should not support all auth options from Istio Gateway as it is specific to Istio and may not be able to applied to other Knative Ingress implementation solutions.
   This method should be the recommended ways for most of users.

2. We can probably allow users to bring their own Istio Gateway (e.g. by passing the Gateway name as the annotation of Knative service). Note that in this case, users need to be completely responsible for their own Gateway, and making sure their Gateway work with VirtualService provided by Knative or the other Gateways provided by Knative. And this method should not considered as a standard API, and should only be recommended to the users who have the complex Gateway auth needs.

[Joon-L]

@ZhiminXiang Makes sense. I think number 2 is valuable since it allows users to leverage all of Istio Gateway's auth options with Knative. There is no simple way to achieve this in the current state, but with this new feature, users can set up their per-service ingress in a more controlled way if they so desire.

[tcnghia]

@Joon-L I think we need to discuss more about https://github.com/knative/serving/pull/5786 at the working group. I am not sure referring to Istio stuffs at Route level is good -- currently Route API doesn't have any reference to Istio, including annotations and labels.

Instead what we have been proposing is to allow a mapping from the visibility label value (sets at Route level) to Gateways (when translating from Ingress with ingress.class=Istio). That way we can also benefit implementations like Gloo and Ambassador, and avoid a leak in abstraction.

[nak3]

@ZhiminXiang I think that the first proosal in https://github.com/knative/serving/issues/5706#issuecomment-539138018 is great idea. Actually I am expecting that we make Knative's cert system pluggable like current nscert by based on standard KCert API.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[knative-housekeeping-robot]

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

[knative-prow-robot]

@knative-housekeeping-robot: Closing this issue.

In response to this:

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

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.