-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unauthenticated health probes and mTLS #590
Comments
Hmm, this is a corner case that I missed. It's possible to implement, but a little scary since you have to give up some automatic certificate verification provided by the go standard library. I think the Alternatively, using |
I think the grpc health endpoint has the same problem, though it is possible I messed something up when testing. This is what I tried
which then gets
Either removing
I can understand this. I also imagine there are people who run this with mTLS exposed to the public internet, who may not want status information publicly available. |
Previously if bazel-remote was using authentication (mtls or basic auth) then unauthenticated health check requests would fail unless also using --allow_unauthenticated_reads. Fixes buchgr#590.
Previously if bazel-remote was using authentication (mtls or basic auth) then unauthenticated health check requests would fail unless also using --allow_unauthenticated_reads. Fixes buchgr#590.
Previously if bazel-remote was using authentication (mtls or basic auth) then unauthenticated health check requests would fail unless also using --allow_unauthenticated_reads. Fixes buchgr#590.
I pushed a fix so that the grpc health service should always be reachable, even if the server has authentication enabled but the client doesn't provide it. For now I left things so that the /status http URL still requires authentication. Aside: watch out if you're using a "localhost" cert- you should specify localhost instead of 127.0.0.1 on the client side. |
Previously if bazel-remote was using authentication (mtls or basic auth) then unauthenticated health check requests would fail unless also using --allow_unauthenticated_reads. Fixes buchgr#590.
With mTLS enabled,
/status
requires a valid client certificate for a successful response, preventing unauthenticated use of/status
as a health check endpoint. (For example as an http probe in kubernetes.)Workarounds such as just using a tcp probe, or a command probe that runs curl with a valid client certificate, do work.
Is there a recommended way of doing health checks when mTLS is enabled?
One solution could possibly be to have another endpoint, on another port, that only provides
/status
and does not require mTLS.The text was updated successfully, but these errors were encountered: