Open asafm opened 1 year ago
Related: The upstream HTTPServer
from the Prometheus Java client can be configured with an Authenticator
, so if #6015 gets merged this could be implemented deferring to upstream API.
@fstab 6105 has several major drawbacks discussed with @jack-berg at #5940 which makes it too big of an obstacle to merge IMO.
Specifically in this issue, supporting an Authenticator
is so easy in terms of added code, I wouldn't want to bring a mountain of code and dependency just to do it.
What's going on now? the PrometheusHttpServer
still can't custom authentication.
PRs to extend PrometheusHttpServerBuilder
with a setAuthenticator(com.sun.net.httpserver.Authenticator)
method are welcome.
I've moved on to another company and don't have time to continue implementing this, sorry.
Is your feature request related to a problem? Please describe. Prometheus HTTP endpoint today is unauthenticated. Some attributes may contain sensitive data, hence having the ability to customize access to it would solve that.
Describe the solution you'd like Ability to customize the
HttpContext
created for metrics handler, using a functional interface (Consumer<HttpContext>
) given in the builder ofProtheusHttpServer
. This will allow setting authentication usingFilter
orAutheticator
.Describe alternatives you've considered Let the apps wrap them selfs with another proxy implementing the authentication. Aside from the complexity of adding another process doing the authentication, there are cases when the authentication is already implemented inside the app for all other HTTP Endpoints, thus it makes sense to do the authentication in the same app using same code and data. Apache Pulsar is an example. Users can provide an
AuthenticationProvider
plugin, and each request to Pulsar will use it for authentication. Forcing Pulsar users to spin up a proxy which implements the Pulsar code for authentication is awfully complicated.