kube-rbac-proxy
kube-rbac-proxy copied to clipboard
feat: Skip upstream certificate validation
Signed-off-by: m.nabokikh [email protected]
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.
Sorry, I was busy. I will try to take a look this week.
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".
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.
@ibihim does it worth rebasing this PR? Are you intend to go further with these changes?
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.
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).
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 https://github.com/kubernetes/kubernetes/pull/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?