#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 anarcat): > 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. So if I understand you right, the blocker for snowflake being integrated in Prometheus monitoring is to make sure we have proper passwords to protect the metrics. This currently means locking down the Prometheus web interface itself which is protected only by a trivial password to keep the bots away, and opening up Grafana to external authentication so that non- TSA folks can access it. In other words, right now we have the current situation: * Prometheus: trivial password, easy to guess, access to raw metrics and rough graphs possible for public * Grafana: single, strong, shared admin password, only accessible to TPA, full graphs and queries possible only for people with the shared password The new situation would be: * Prometheus: hard, strong, shared password only accessible to TPA for debug purposes (or accessible only to localhost) * Grafana: LDAP authentication or some other mechanism to grant people outside TPA access to the server There are two problems with this: 1. we're hesitant in setting LDAP authentication in Grafana, because we don't want to have monitoring depend on LDAP to work but also because we're hesitant in putting more stuff in LDAP in general (the less stuff has access to it the better) 2. we might *want* to provide (semi-)public (with trivial password) access to those graphs for transparency and ease-of-access reasons What TPA is proposing now is to setup another server to monitor external resources. It would solve problem 2 above, but not problem 1. It would also conflate two distinct problems * "external resources should not be monitored alongside internal resources" * "some metrics should stay private" problem Because, of course, maybe some internal resources should stay private and external resources should be public, and vice versa. I'm not sure how to resolve this conendrum. I don't have a clear view of what goes where, to be honest. There were a few requests already for external monitoring and I must admit I somehow have trouble keeping track of things. :) There are at least two concurrent requests from the anti-censorship team, one of which was resolved internally (#30006) so I hope you understand I can get a little confused... It's also unclear to me what the endgame is with snowflake: there was talk of migrating it inside TPO, for example... -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30023#comment:7> 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