The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

473180 (2) [Avatar] Offline
First I want to say thanks for the very good explanations.

Maybe it's my lack of experience but there's something I don't understand in this section.

My first confusion is in this quote :
Currently, the Ingress can handle incoming HTTPS connections, but it terminates the TLS connection and sends requests to the services unencrypted. Let’s take a quick look at how to configure Ingress to support TLS.
... Since the Ingress terminates the TLS connection, it needs a TLS certificate and private key to do that.

I'm not sure what the certificate and key are going to be used for. Is it to reencrypt on the other side of the load balancer ? Probably something obvious that I don't know.

My other confusion is when testing:
We can now use HTTPS to access our service through the Ingress:
$ curl -k -v

My question is something like this : I guess this tls connection is between the client and the ingress(nginx), but how does this proves that the requests between nginx and the services are now encrypted. Again probably something obvious, but since this book has so many good explanations, I was hoping to get one here.
Marko Lukša (69) [Avatar] Offline
During my final review, I also found that part confusing, so I changed it. But now, based on your comment, I've realized I need to improve it further.

I'll replace the first sentence with the following:
When a client opens a TLS connection to an Ingress controller, the controller terminates the TLS connection. The communication between the client and the controller is encrypted, whereas the communication between the controller and the backend Pod isn't. The application running in the Pod doesn't need to support TLS. For example, if the Pod runs a web server, it can accept only HTTP traffic and let the Ingress controller take care of everything related to TLS. To enable the controller to do that, you need to attach a certificate and a private key to the Ingress.

Does that make the section clearer?

BTW: OpenShift has a feature called Routes, which are basically the same as Ingresses. The difference is that you can configure the TLS termination type on Routes (there are three options: passthrough, edge termination and re-encryption). In the future, Ingresses will most likely support this as well.
473180 (2) [Avatar] Offline
Yes, is more clear now. I guess, my confusion was that at the beginning of the paragraph, it made me think that the controller was already handling TLS. Now it doesn't say that, and it explains better that the certificate and key are for that. Thanks.