Remove basic auth from node exporter about node_exporter HOT 14 CLOSED

Built-in basic auth would be appreciated from my end as well. Of course I can reverse-proxy the node-exporter, but that’s one more config file and dependency in my setup :|.

from node_exporter.

As a reverse proxy is now needed for any security/authentication measurement, shouldn't the node exporter only listen on localhost by default?

from node_exporter.

@juliusv Sorry, my goal was to express strong disagreement, not to be impolite.

For perspective and reference, here's a list of competing/related tools that have TLS:

• CollectD
• Icinga
• InfluxDB
• Munin
• Nagios
• OpenTSDB
• Riemann
• Sensu
• StatsD
• Zenoss (couldn't find proper docs here, but their agents talk SSL, too)

I was going to add a list of monitoring tools that don't implement TLS as well, but couldn't find any. Not a single one.

from node_exporter.

Yes, I agree with you. But I think system must have his own basic simple auth for simple installation with security support. It is very important, beleave me:) This option can be disable by default.

from node_exporter.

I agree with @svagner. I understand the desire to not go down the slippery slope of supporting a plethora of auth types, but having basic auth in there is very valuable for people who want simple protection and don't want the added cost of installing, configuring, and running a reverse proxy.

from node_exporter.

Agreeing in general. I also think this should be added (well, no suprise given that I added basic auth back then).

from node_exporter.

Why? May be you should add oppotunity for anable or disable this auth? The point is that many systems doesn't have any reverse proxyes and install this proxies at all nodes isn't correct politic for organization (in highload systems it can give many problems). If we install some reverse proxy we have more one point of deniel. It isn't good.

from node_exporter.

Let's say we did support basic auth (which doesn't seem like the plan), then we'd also need to support TLS to make the basic auth useful. So now we have a much more complex problem already (there are many ways of configuring TLS). There's an FAQ item on this now btw.: https://prometheus.io/docs/introduction/faq/#why-don't-the-prometheus-server-components-support-tls-or-authentication?-can-i-add-those?

from node_exporter.

This should really be implemented in prometheus where it
can be peer-reviewed and is then available to all users.

Shifting the burden onto your users is not only a royal pain in the ass
but also results in brittle and insecure deployments all over the place.

node_exporter is supposed to run on many hosts, which in most environments
translates to many different OS's and patch levels.

Prometheus should not ask admins to build and maintain multi-platform
training wheels for something as basic as their monitoring probe.

from node_exporter.

Yes, transport security and auth very much on my mind. I've already added this to the agenda for the next developer's summit which happens in a couple weeks as part of PromCon.

This issue is not the place to discuss changes, as it's an ecosystem wide policy change.

Feel free to start a conversation on the Prometheus community developers list. We need to consider the whole scope of securing monitoring endpoints.

Please keep the discussion professional. Rants and aggressive language will not be tolerated.

from node_exporter.

Basic auth is just one of many potential ways that a user could do auth, there's LDAP, Kerberos, OTP plus all the directory systems and policies that may be associated with them.
Rather than spending an ever increasing amount of time creating and maintaining such integrations, we've chosen to delegate the responsibility to other projects that handle this problem already.

from node_exporter.

I understand this slippery slope as well +1 to adding in only basic support and an option to disable (if both are blank) or a flag.

from node_exporter.

@m-o-e "should" is a subjective judgement. There's pros and cons to each side, but the fact is that anything that is in Prometheus proper needs to be maintained by Prometheus people, and that needs capacity and ongoing commitment.

I am personally ambivalent about this issue, as I feel both sides have good arguments. I would personally like to have a Prometheus supporting all that, I'm less sure about wanting to maintain it :) People like @SuperQ (also Prometheus team) are very much in favor of adding TLS+auth to Prometheus components themselves, but that isn't consensus yet. @brian-brazil has been historically the most cautious person against it, but also indicated that he might be willing to reconsider that if someone puts together a security and response plan for all this, along with recommendations from security people on what to watch out for. I think there was a mailing list thread about this once started by @SuperQ, maybe he can dig it out.

from node_exporter.

I'd suggest to raise this general topic on the prometheus mailing list and discuss it there. Not sure what the latest state of this discussion is.

@Jasper-Ben Yeah, that could make sense indeed.. @SuperQ wdyt?

from node_exporter.