#30023: improve grafana authentication -------------------------------------------------+--------------------- Reporter: anarcat | Owner: tpa Type: task | Status: new Priority: Medium | Milestone: Component: Internal Services/Tor Sysadmin Team | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: -------------------------------------------------+---------------------
Comment (by cohosh): Replying to [comment:5 anarcat]: > i am not familiar with configuring prometheus to fetch metrics from proxy. if I understand you correctly, there's a `proxy_url` setting that can be added to do that? I cannot confirm that, in any case. > > but sure, that could be possible. i am not sure how that relates to this ticket, however, which is specifically about Grafana authentication, not really about how Prometheus talks with its exporters, for which there is no ticket right now - I thought we had resolved that by selecting only a subset of metrics, but I haven't followed the entire conversation in #29863. What I saw on IRC was specifically that question: > > > In IRC it also sounded like there was little-to-no authentication on the server that displays these metrics after scraping. Is that the case? > > So I thought we were talking about the "server that displays the metrics", ie. Grafana (or the Prometheus frontend), which is why I pointed you here. > > But yes, we have a similar problem with the exporters: in theory, someone could do IP spoofing and bypass those firewalls to scrape the metrics off. In practice, those stunts are actually quite hard to pull because you need to do pretty hardcore stuff like BGP hijacking, because of TCP negociations (at least, as far as I understand it, correct me if I'm wrong). But I'm not sure the prize (metrics) would be worth the trouble (upsetting the internet's routing table). > Ah, you're right. I was conflating these two separate issues. We can leave this ticket for the grafana access issue only. > As for the specific solution proposed here, I'd be tempted to simply add HTTPS and username/password authentication, as it's something I understand better and it doesn't require the Tor network to be operational. I always feel a little ackward using Tor to monitor internal infrastructure - I'm all for eating our own dogfood, but when it comes to monitoring, I feel a little less comfortable and prefer redundancy. ;) > > That said, the idea of setting up a secondary server would be that other kind of tricks could be tried by other teams, so I don't want to be blocking nice initiatives like this. This is just my grain of salt which I hope will be useful! Okay, HTTPS + a stronger password to access the graphs sounds fine to me right now. I think especially with our current policy of only exporting a small amount of metrics we don't have much to risk at the moment. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30023#comment:6> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs