Skip to content
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

Closed
prateekjainaa opened this issue Nov 22, 2019 · 7 comments
Closed
Labels
area/tls Issues or PRs related to TLS support. blocked/needs-design Categorizes the issue or PR as blocked because it needs a design document. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
Milestone

Comments

@prateekjainaa
Copy link

prateekjainaa commented Nov 22, 2019

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?

@davecheney
Copy link
Contributor

davecheney commented Nov 22, 2019 via email

@prateekjainaa
Copy link
Author

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.

@davecheney
Copy link
Contributor

davecheney commented Nov 22, 2019 via email

@prateekjainaa
Copy link
Author

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.

@davecheney
Copy link
Contributor

davecheney commented Nov 22, 2019 via email

@prateekjainaa
Copy link
Author

yes, that would be really nice feature for moving existing clusters to use contour controller.

@davecheney davecheney added help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. blocked/needs-design Categorizes the issue or PR as blocked because it needs a design document. labels Nov 23, 2019
@davecheney davecheney added this to the Backlog milestone Nov 23, 2019
@davecheney davecheney changed the title ssl-passthough via ingress controller Add tis-passthrough support to networking.k8s.io/ingress.v1beta1 Nov 24, 2019
@jpeach jpeach changed the title Add tis-passthrough support to networking.k8s.io/ingress.v1beta1 Add tls-passthrough support to networking.k8s.io/ingress.v1beta1 Nov 26, 2019
@jpeach jpeach added the area/tls Issues or PRs related to TLS support. label Jul 1, 2020
@xaleeks
Copy link

xaleeks commented Apr 13, 2021

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.

@xaleeks xaleeks closed this as completed Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/tls Issues or PRs related to TLS support. blocked/needs-design Categorizes the issue or PR as blocked because it needs a design document. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
Projects
None yet
Development

No branches or pull requests

4 participants