Disable Grafana external snapshot publishing

The fix/etc/grafana/grafana.ini

[snapshots]
external_enabled = false

What is enabled by default

From defaults.ini:

[snapshots]
enabled = true
external_enabled = true
external_snapshot_url = https://snapshots.raintank.io
external_snapshot_name = Publish to snapshots.raintank.io

A Grafana snapshot captures a dashboard together with the data currently in it — the point being that it renders without needing the original data source. It is a genuinely useful feature for sharing a moment in time with someone who cannot query your backends.

external_enabled = true adds a second button that uploads that snapshot to a public server run by Grafana Labs, and returns a URL. Anyone with the link can view it.

Unlike most items on this checklist, this is not a default that is fine until someone breaks it. It is a data-egress path that is on out of the box, and the person who uses it is a normal user doing something the interface offered.

Why it is easy to do by accident

The publish button sits next to the local share option in the same dialog. The distinction between “snapshot” and “publish snapshot to snapshots.raintank.io” is one line of text, and the second is faster for the thing people usually want — sending a colleague a link that works.

What actually leaves is the panel data: hostnames, service names, error rates, request volumes, query results, whatever was on screen. On an infrastructure dashboard that is an inventory of your estate. It is also, in most organisations, an unreviewed transfer of operational data to a third party, and that is a compliance question as much as a security one.

The snapshot URL is unguessable rather than protected — there is no authentication in front of it. Deleting a published snapshot requires the delete key returned at creation time, which the person who published it usually did not keep.

Keep local snapshots

Setting external_enabled = false removes the publish-externally button and leaves ordinary snapshots working. Users can still snapshot a dashboard and share it within your Grafana, which covers the legitimate need without the egress.

Turn snapshots off entirely only if you have a specific reason:

[snapshots]
enabled = false

Note that local snapshots are still visible to anyone who can log in and are not scoped by dashboard permissions in the way people assume — so they are a sharing feature, not a secure one.

Self-hosting the external server

If teams genuinely need shareable-outside links, point the feature at infrastructure you control rather than removing it:

[snapshots]
external_enabled = true
external_snapshot_url = https://snapshots.internal.example.com
external_snapshot_name = Publish to internal snapshot server

The name string is what appears on the button, so make it say where the data is going. That single change turns an invisible third-party upload into a visible internal one.

Verify it worked

Check the resolved configuration, remembering that no output means the default — and here the default is the thing you are looking for:

grep -A5 '^\[snapshots\]' /etc/grafana/grafana.ini
docker inspect grafana --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -i SNAPSHOT

Ask the running instance what it resolved, which is more reliable than the file:

curl -sS -u "$GF_ADMIN_USER:$GF_ADMIN_PASS" \
  https://grafana.example.com/api/frontend/settings | tr ',' '\n' | grep -i snapshot

The externally-published option should be reported as disabled, and the raintank.io URL should not appear.

Then find out whether it has already been used, which is the more urgent question:

curl -sS -u "$GF_ADMIN_USER:$GF_ADMIN_PASS" \
  https://grafana.example.com/api/dashboard/snapshots | \
  python3 -c 'import json,sys; [print(s["name"], s.get("external"), s.get("externalUrl","")) for s in json.load(sys.stdin)]'

Any row with external true is data that has already left. The externalUrl is the public link.

Before you apply this

Low risk to apply. The only thing that breaks is the publish-externally button, and anyone relying on it is relying on the behaviour this page is about.

The harder part is what to do about snapshots already published. You cannot delete them from the Grafana UI without the delete key issued at creation, and that key is generally long gone. If something sensitive was published:

1. Get the list from the API command above and record every externalUrl.

2. Check whether the local record retains a delete key:

   curl -sS -u "$GF_ADMIN_USER:$GF_ADMIN_PASS" \
     https://grafana.example.com/api/dashboard/snapshots | grep -o '"deleteKey":"[^"]*"'

3. Where there is no key, contact Grafana Labs to request removal — that is the only remaining route for their hosted service.

4. Treat the data as disclosed in the meantime, and rotate anything a hostname or credential fragment in the snapshot would compromise.

Removing the local snapshot record does not remove the published copy. The two are independent, which is exactly the property that makes this worth disabling before it is used rather than after.

sudo systemctl restart grafana-server

Related

• Grafana anonymous access is already off — the other way dashboards reach people without a login.
• Restrict data source permissions — limiting what ends up in a panel in the first place.