Basic Authentication to Prometheus web endpoint

[prasann...@gmail.com]

I noticed that both AuthManager and Prometheus web endpoints are wide open. They include configuration information including service keys for various web services like PagerDuty. Securing these web endpoints would require additional service/reverse_proxy to add some kind of authentication. My goal with this fix was to add a very simple bare-minimum, optional authentication mechanism. I didn't find anything accessible in the mailing lists that implied someone was working on this.

How to use it:

Caveat: I tried adding the config in the config.yml but the way the web struct is initialized I only get the string form of config and would have to parse again.
./prometheus -config.file=./prometheus.yml -web.auth-enabled=true -web.basicauth.username test -web.basicauth.password '$1$dlPL2MqE$oQmn16q49SqdmhenQuNgs1'

where the password is the digest generated by htpasswd for "hello"

I'm sure there are many stylistic changes that could be made but I'm neither expert on prometheus or Go, so I'm open to any criticisms and improvements to the code. I do think at least having basic authentication for web endpoints is warranted. If there are better ideas in motion, I'd be curious when they'd be implemented.

Also, sorry for breaking the build on my branch. I'm using go-http-auth to do this and somehow it's not getting pulled/detected in the CI server.

[Will Rouesnel]

This is timely - for rolling out prometheus at my organization I was
about to look into adding LDAP auth support to the alertmanager
frontend. That notably needs some options to configure who can silence
what alerts.

[Julius Volz]

Thanks for the interest! Unfortunately, we have decided against integrating authentication and SSL in Prometheus itself and advise providing that functionality via reverse proxies instead - see the discussion on https://github.com/prometheus/prometheus/pull/972 for more context.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julius Volz]

Good point about silencing restrictions in Alertmanager though. We don't have any plans to add authentication and user management to Alertmanager, but at least some kind of protection against "accidental oversilencing" (always requiring some label to be specified or similar) would be quite important. I realize user management will be important to some companies, but that's at least not in our current roadmap for the AM. One workaround could be to run multiple AMs (e.g. one per service or what your auth boundaries are) and secure them individually.

[Brian Brazil]

On Mon, Aug 10, 2015 at 2:16 PM, Julius Volz <jul...@soundcloud.com> wrote:

Good point about silencing restrictions in Alertmanager though. We don't have any plans to add authentication and user management to Alertmanager, but at least some kind of protection against "accidental oversilencing" (always requiring some label to be specified or similar) would be quite important. I realize user management will be important to some companies, but that's at least not in our current roadmap for the AM. One workaround could be to run multiple AMs (e.g. one per service or what your auth boundaries are) and secure them individually.

We had informally discussed having a feature where you could have unittests of sort applied to new silences, and it'd be rejected if it silences all of a group of alerts. 

Brian

[Will Rouesnel]

Even if actual access control is low priority, there's a UX element here which is that when someone clicks "silence" it'd be nice if the name field auto-filled.

Presuming we take care of auth with frontend proxies (which is fine - basic auth + nginx and pam works great and is very flexible) - it'd be nice to have some defined HTTP headers we could pass to the backend to specify things like this, and there's a kernel of an access-control system like this if you could disable certain functions with them (like the delete timeseries option in the Prometheus HTTP api).

Would that separation of concerns work?

[Brian Brazil]

On Fri, Aug 28, 2015 at 8:02 PM, Will Rouesnel <w.rou...@gmail.com> wrote:

Even if actual access control is low priority, there's a UX element here which is that when someone clicks "silence" it'd be nice if the name field auto-filled.

Presuming we take care of auth with frontend proxies (which is fine - basic auth + nginx and pam works great and is very flexible) - it'd be nice to have some defined HTTP headers we could pass to the backend to specify things like this, and there's a kernel of an access-control system like this if you could disable certain functions with them (like the delete timeseries option in the Prometheus HTTP api).

Would that separation of concerns work?

I think filling in silence username (which is currently a mandatory field) from a header is reasonable. More general authorization would need some thought so that we don't end up having to build a complete system for it. For the particular example of time series deletion, that should be so rare that restarting Prometheus with different flags to enable it temporarily should be sufficient.

Brian

--

Brian Brazil

www.robustperception.io