feat: Skip upstream certificate validation

[nabokihms]

Signed-off-by: m.nabokikh maksim.nabokikh@flant.com

Motivation

A proxy always comes in front of upstream. Some upstream, instead of HTTP requests, serve HTTPS requests with self-signed certificates (this is better than having no TLS at all).

Additional information

I also moved all transport-related code pieces to the transport.go.

[ibihim]

Sorry, I was busy. I will try to take a look this week.

[ibihim]

I like that you moved transport-related code pieces to transport.go...

... but I am not quite convinced that unverified certs are a good thing or better than unencrypted traffic.

If you could look into the network traffic, you most probably would be capable of a MITM attack, while the option gives a false feeling of "security".

[nabokihms]

My case is simple: an application that automatically generates self-signed certificates and always serves HTTPS. What I want to do is to make such applications listen on 127.0.0.1 and ignore its self-signed certificate. If you want, I can add an additional check that the upstream certificate can only be ignored for upstream that listens on localhost.

[nabokihms]

@ibihim does it worth rebasing this PR? Are you intend to go further with these changes?

[stlaz]

I'm not a big fan of ignoring certificate verification. I'd suggest finding a way to generate the certificate and supply its signer to the upstream-ca option of the proxy, e.g. via initContainers.

[nabokihms]

For my use case, it is okay not to have certificates at all, e.g., to serve HTTP. I successfully use kube-rbac-proxy to protect HTTP applications. However, I cannot protect applications that use selfsigned certificates (and cannot force developers of applications to do as I wish).

[stlaz]

I'd like to assume an application using self-signed certs would publish at least the serving certificate in a well-known location - likely specific per application, but the upstream trust location is configurable in the kube-rbac-proxy already anyway.

This means we could reuse the logic from kubernetes/kubernetes#123400 (unfinished) to load the trust dynamically from the kube-rbac-proxy. We may want to ask (in the mentioned PR) for a loading error backoff upon start to get a bit of lead time for the app to be able to supply the cert.

Does that sound feasible?