Support encrypted traffic between ingress and queue-proxy

[nak3]

As described in the feature docs:

the HTTP Proxy (KIngress) needs to be able to accept certificates for both the activator (in the knative-serving namespace) and the Revision pods (in the user namespace). There are three ways to manage this: ... snip ... For the initial Alpha release, we will implement approach 2 and reduce scope by keeping the activator always (and only) in the set of Knative Revision endpoints exposed to the KIngress.

the alpha release does not support the encrypted traffic between ingress and queue-proxy but it is a temporary state and we should support it.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[nak3]

This is possible to support if we sign the server certs in activator and queue-proxy by the same CA and SAN.

However, it is better to support different SAN or CA for the server certs on each namespace, which means the support of the encrypted traffic between ingress and queue-proxy is very difficult.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[psschwei]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[psschwei]

/remove-lifecycle stale

[nak3]

Just linking to the discussion https://github.com/knative/serving/pull/13005#discussion_r905743202

This is achievable with the current same CA and same SAN but we should try SNI.

[ReToCode]

With the latest discussion, we'll focus on doing the multi-SAN approach for Istio + Kourier and let activator stay in path for contour + gw-api as long as they do not support the multi-SAN approach. So no need for SNI in activator for now.

/close

[knative-prow[bot]]

@ReToCode: Closing this issue.

In response to this:

With the latest discussion, we'll focus on doing the multi-SAN approach for Istio + Kourier and let activator stay in path for contour + gw-api as long as they do not support the multi-SAN approach. So no need for SNI in activator for now.

/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.