Fluxgate for Grafana
Grafana is awesome and it’s a super-useful tool for exploring your data — we use it heavily for internal graphs and for exposing graphing capabilities to customers. However, one area Grafana falls down on is isolating specific things from specific users. It’s difficult if not impossible to provide access to only specific tables or measurements, and furthermore even harder to decide how to enforce those limitations based what user they log into Grafana as when everything is backed by the same InfluxDB cluster.
To solve some of these problems, we developed an internal InfluxDB proxy server called Fluxgate.
InfluxDB’s query interface is HTTP, so it is easy to make a little HTTP server which can proxy requests to a second upstream server (in this case, the real InfluxDB cluster). Fluxgate takes in these requests and looks at the HTTP Basic auth to determine the user from our own accounts systems. Naturally, since it’s basic auth, you’ll want to use HTTPS, but this user/password combo doesn’t have to be the same as anything that provides authorisation for anything other than Fluxgate. Equally, if you are using auth on InfluxDB itself as well, you can specify both sets of auth by using query parameters too.
From the user, Fluxgate can then determine exactly what services and features the user has available to them and can map those directly to prefixes which we use to shard our InfluxDB measurements by service. With all of this information and the magic of open-source, we can use the query parser from InfluxDB itself to pull apart the queries being made, check them against basic whitelists (no writes allowed, etc) and rewrite them to explicitly limit themselves to only measurements the user has access to. Since this is happening at the AST level, we can do a number of quite fine-grained checks and edits without hacky and error-prone solutions (such as string replacement with regexes), then reconstruct the query and pass it down the chain to InfluxDB proper.
At present, Fluxgate limits access not only to queries against measurements, but also to any of the more informational queries such as SHOW MEASUREMENTS, to prevent discovery and enumeration of other customer IDs. All non-whitelisted queries are rejected by returning a standard InfluxQL result structure with an error message, as are most queries that use regexes or other query methods that attempt to work around access restrictions. This does limit queries to more exact searches, but for most usages this has not proven to be an issue.
In this manner, fluxgate allows us to filter exactly what databases, measurements, and types of query a user is allowed to use. To use it, all you need to do in Grafana is setup an InfluxDB datasource using the InfluxDB URL set to Fluxgate with correct basic auth details and everything transparently works. The cool thing about this is that we don’t even need to provide Grafana ourselves to customers — if they have their own Grafana system they want to integrate with, they can just add Fluxgate as a datasource themselves into their own monitoring and graphing systems.
