In Traefik 1.7.4 in a docker-swarm environment we had SSL termination occurring on several of our back-end services.
In Traefik 2.0.2 we are up and running with all our non-HTTPS services using HTTP routers through middleware etc.
However, we are struggling getting HTTP routing to work for our HTTPS back-end services and getting 404 messages.
Is it possible to do this with HTTP style routing in 2.0, or must we use TCP routers? We would rather not use a TCP router for this use case so that we can implement path stripping/morphing, http to https redirection etc consistently across our web estate.
In terms of verifying our environment:
An https curl (-k, i.e. insecure) call to the service IP/port listed as a service in Traefik dashboard yields the expected result, and is logged in the service's back end nginx log. However, no other requests are logged meaning this is not a URL path issue with our service. Our Traefik configuration is just not hitting it.
An https curl call made via Traefik with access logging does show the call as having been made with a 404 but as explained does not find the back-end service.
The Traefik dashboard view is shown below. As can be seen there is no middleware needed for this situation - which I don't think is the problem - because I've got the same behaviour implementing a do-nothing sequence of middleware steps (add and then remove same prefix).
Thanks for responding. Are you saying that with Traefik 2.0 there is no way to configure HTTPS termination on the container without using a TCP router?
We didn't need a TCP router in v1.7 to achieve HTTPS container termination and are hoping not to have to use a TCP router with v2.0.
Of course TCP router functionality is awesome and we are very happy it has been implemented for other use cases.
It is possible but in my view, it is not ideal. If you want pass-through, then yes, TCP is the only option, otherwise you can terminate SSL on traefik, and then have traefik make another SSL connection that is terminated on your app. In case of docker/kubernetes you will have to use insecureSkipVerify on service transport to make it work, since traefik will be contacting your app by IP and cert check will likely fail.
Yes, traefik 2.0 was designed to improve that shortcoming
So if the objective is to get termination on the container itself, and only on the container, yet benefit from http router rules it sounds like this not supported and so a form of regression vs 1.7.x functionality.
I understand based on your comments that we could terminate and then re-establish another SSL connection but that is not desired. And I understand that with TCP routers we could passthrough - but then not have the benefit of the http router rules.
Wait what? If connection being passed from traefik is SSL and it is NOT terminated on traefik, how on earth can it manipulate the encrypted data it has no access to?
I hear you and confess I'm no expert, and that we're very shortly going to get above my grade level ;o). Hence all the questions.
In our Traefik 1.7 which I thought was resulting in end-to-end encryption (without termination/re-encryption) our configuration is pretty simple, like this example:
I'm sure grafana in this instance is only running https. And I'm sure I'm encrypting everything because I'm watching the wire using tcpdump.
Are there any tools/means you recommend to figuring out whether end-to-end encryption is the behaviour? I've done curl -vvv and run some openssl commands but to be honest I'm not sure how to interpret the output.
The answer to the headline question that I asked at the top of this thread based on @zespri's input is:
The only way to perform HTTPS termination solely on the container service (without doing it on Traefik) is to use a TCP router.
Of course, it is possible to do HTTPS termination on Traefik, and then subsequently establish a secondary HTTPS connection to a service.
Additional details post last comment:
By docker exec'ing into the traefik container and then running netstat it is clear that we are in fact (contrary to original expectations) terminating, and then re-establishing additional https connections in our Traefik 1.7.3 installation.
So, declaring our HTTP router as TLS, and enabling the insecureSkipVerify option, just as @zespri explained achieves exactly the same effect as our Traefik 1.7.3 installation.