TLS termination spread out making things too complicated

[consideRatio]

We have both TLS termination (encrypt outbound/decrypt inbound traffic using certificates) in different places, depending on using automatic certificate acquisition from Let's encrypt or if they are manually provided.

When certificates are automatically acquired, they are currently acquired using kube-lego or traefik after #1539, and then they are currently used for TLS termination by an nginx proxy and after #1539 using a traefik proxy that only acts to manage TLS termination.

When certificates are manually provided by the user of the helm chart somehow, TLS termination is done by the CHP (configurable http proxy) that has a purpose to dynamically update its routing of traffic by instructions of JupyterHub. In the future we aim to replace this with another traefik proxy or the same as used to do the TLS termination and certificate acquisition after #1539.

I want this issue to represent the effort to manage TLS termination at a single location no matter how a certificate was acquired if that is possible. This issue was created while reviewing #1539 and in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/1539#pullrequestreview-343546530 there is some confusion made explicit that in my mind can justify reducing the complexity a bit.

[manics]

Is it worth including the internal_ssl work in this too, since it's another set of certificates that needs to be maintained? https://github.com/jupyterhub/kubespawner/pull/386

[consideRatio]

It certainly relates, I figure we want to aim for all communication being encrypted.

Between user browsers and proxy, proxy and user pods, proxy and hub, for example. And currently we have two proxies, the initial autohttps TLS termination proxy, and the CHP proxy dynamically routing traffic etc.

We can have another issue tracking 100% encrypted traffic perhaps?

[betatim]

I think a good action item for this issue would be to investigate what it would take to move the manually provided certs to traefik (assuming #1539 is merged). It might not even be possible or sensible to have an extra proxy "just to do" TLS termination in the manual certs case but it would allow us to have it all in one place.

[consideRatio]

@betatim I'd like to have TLS termination centralized, but also TLS acquisition, and jupyterhub's need for a configurable proxy - all in one place. That way, we will reduce the amount of different edges that could need encryption to accomplish 100% encrypted traffic.

Challenges:

1. To not always have automatic certificate acquisition but sometimes have it, without needing to adjust tech.
2. To not have an additional network path between TLS termination and the actual jupyterhub logic in another proxy/hub/pods, as we do now with current and post #1539 setup of automatic HTTPS.

The best outcome I think, is to have one single traefik that does the work of

[yuvipanda]

A while ago, I drew a diagram that might be useful: https://discourse.jupyter.org/t/jupyterhub-traffic-flows-how-they-are-secured/1246

[yuvipanda]

I'm going to close this as I think it was simplified quite a bit with my work in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/1539