-
Notifications
You must be signed in to change notification settings - Fork 674
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
Add tls-passthrough support to networking.k8s.io/ingress.v1beta1 #1931
Comments
Thank you for your issue. To confirm, are you asking for us to backport httpproxy’s TLS passthrough to contour’s k8s ingress object support?
… On 23 Nov 2019, at 03:16, Prateek ***@***.***> wrote:
We have an application which itself handles SSL handshake i.e, HTTPS. Now, this application runs fine till now in k8s as, nginx-ingress controller (and corresponding Ingress object) supports this feature via,
--enable-ssl-passthrough
argument. As we are planning to move our clusters to use contour based ingress controller, this is no longer working for us. Is there a similar configuration in contour/envoy?
We know from documentation
issue 15
documentation
but this is done via HTTPProxy object; which means application needs to be updated. Is there a way to achieve the same by just modifying contour ingress-controller?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks for the prompt reply @davecheney . As I said, we are trying to port our cluster to use contour based ingress controller. Most of our services handle their ssl connections themselves. So, our nginx ingress controller was running in ssl-passthrough mode.
No, I was just asking whether there is a corresponding feature available in contour ingress controller or not. But what it means is, existing Ingress objects cannot be reused and new HTTPProxy objects will have to be created. We are currently targeting close to 70 services so, it would be an issue to update all of them and run full regression (because change is in services rather than cluster). But I really think that such a feature would be very useful to have. If you want, we can open separate issue to get this feature in. |
Thank you for your reply. I think the answer to your question is; contour supports tls passthrough via the HTTPProxy crd.
… On 23 Nov 2019, at 08:33, Prateek ***@***.***> wrote:
Thanks for the prompt reply @davecheney . As I said, we are trying to port our cluster to use contour based ingress controller. Most of our services handle their ssl connections themselves. So, our nginx ingress controller was running in ssl-passthrough mode.
To confirm, are you asking for us to backport httpproxy’s TLS passthrough to contour’s k8s ingress object support?
No, I was just asking whether there is a corresponding feature available in contour ingress controller or not. But what it means is, existing Ingress objects cannot be reused and new HTTPProxy objects will have to be created. We are currently targeting close to 70 services so, it would be an issue to update all of them and run full regression (because change is in services rather than cluster).
But I really think that such a feature would be very useful to have. If you want, we can open separate issue to get this feature in.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I suspected that but just wanted to confirm before making our estimations. Are there any plans to incorporate such feature in short while? If not, feel free to close this ticket. |
I’m sorry I wasn’t clear. Contour implements tls passthrough on a per vhost basis via the field in the HTTPProxy crd, not a flag passed to the ingress controller.
If you would like us to add support for tls passthrough in the k8s ingress object this would probably be via an annotation on the object.
… On 23 Nov 2019, at 08:42, Prateek ***@***.***> wrote:
I suspected that but just wanted to confirm before making our estimations. Are there any plans to incorporate such feature in short while? If not, feel free to close this ticket.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
yes, that would be really nice feature for moving existing clusters to use contour controller. |
I don’t think we’ll be trying to support this on Ingress. The broader community has moved onto gateway API and we already have a good solution on our HTTPProxy CRD. Total feature parity is not the goal of Contour here. I’m closing this for now, but feel free to keep the discussion going if still unclear. |
We have an application which itself handles SSL handshake i.e, HTTPS. Now, this application runs fine till now in k8s as, nginx-ingress controller (and corresponding Ingress object) supports this feature via,
argument. As we are planning to move our clusters to use contour based ingress controller, this is no longer working for us. Is there a similar configuration in contour/envoy?
We know from documentation
issue 15
documentation
but this is done via HTTPProxy object; which means application needs to be updated. Is there a way to achieve the same by just modifying contour ingress-controller?
The text was updated successfully, but these errors were encountered: