kube-rbac-proxy icon indicating copy to clipboard operation
kube-rbac-proxy copied to clipboard

feat: Skip upstream certificate validation

Open nabokihms opened this issue 3 years ago • 7 comments

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.

nabokihms avatar Nov 01 '22 19:11 nabokihms

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

ibihim avatar Nov 28 '22 13:11 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".

ibihim avatar Nov 30 '22 17:11 ibihim

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 avatar Dec 11 '22 22:12 nabokihms

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

nabokihms avatar Dec 14 '22 10:12 nabokihms

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.

stlaz avatar Mar 25 '24 10:03 stlaz

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).

nabokihms avatar Apr 08 '24 19:04 nabokihms

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?

stlaz avatar Apr 11 '24 09:04 stlaz