1
0
Fork 0
Commit Graph

3 Commits (7158ff89df72c8f170fbfce672137c32c17f1186)

Author SHA1 Message Date
Dustin eb754d9112 grafana: Update to 11.5.5
The legacy alerting feature (which we never used) has been deprecated
for a long time and removed in Grafana 11.  The corresponding
configuration block must be removed from the config file or Grafana will
not start.
2025-06-05 07:06:40 -05:00
Dustin f468977d91 grafana: Enable send_user_header option
I discovered today that if anonymous Grafana users have Viewer
permission, they can use the Datasource API to make arbitrary queries
to any backend, even if they cannot access the Explore page directly.
This is documented ([issue #48313][0]) as expected behavior.

I don't really mind giving anonymous access to the Victoria Metrics
datasource, but I definitely don't want anonymous users to be able to
make Loki queries and view log data.  Since Grafana Datasource
Permissions is limited to Grafana Enterprise and not available in
the open source version of Grafana, the official recommendation from
upstream is to use a separate Organization for the Loki datasource.
Unfortunately, this would preclude having dashboards that have graphs
from both data sources.  Although I don't have any of those right now, I
like the idea and may build some eventually.

Fortunately, I discovered the `send_user_header` Grafana configuration
option.  With this enabled, Grafana will send an `X-Grafana-User` header
with the username of the user on whose behalf it is making a request to
the backend.  If the user is not logged in, it does not send the header.
Thus, we can detect the presence of this header on the backend and
refuse to serve query requests if it is missing.

[0]: https://github.com/grafana/grafana/issues/48313
2024-02-22 07:10:01 -06:00
Dustin 3439ce1f13 grafana: Deploy Grafana
Now that Victoria Metrics is hosted in Kubernetes, it only makes sense
to host Grafana there as well.  I chose to use a single-instance
deployment for simplicity; I don't really need high availability for
Grafana.  Its configuration does not change enough to worry about the
downtime associated with restarting it.  Migrating the existing data
from SQLite to PostgreSQL, while possible, is just not worth the hassle.
2024-01-27 22:01:08 -06:00