Grafana anonymous access is already off — verify it

The fix/etc/grafana/grafana.ini

[auth.anonymous]
enabled = false

[users]
allow_sign_up = false
allow_org_create = false

All three are already the defaults. Writing them down makes the intent explicit and survives the next person who edits the file.

These are Grafana’s defaults, not fixes

From defaults.ini:

[auth.anonymous]
enabled = false
org_role = Viewer

[users]
allow_sign_up = false
allow_org_create = false

“Disable anonymous access in Grafana” is standard hardening advice and it describes the shipped state. As with memcached’s UDP, the useful action is not to apply the setting — it is to check whether somebody applied its opposite.

They often have, and for a reason that made sense at the time: a status dashboard for a team, a screen in an office, a public metrics page. Anonymous access is the fastest way to make that work, and it is rarely revisited when the dashboard next to it starts showing something sensitive.

What “just a Viewer” gets

Anonymous users get org_role = Viewer by default, which sounds contained. It is less contained than it sounds.

A Viewer can see every dashboard in the organisation — not only the one you meant to share — and dashboards are built on data sources. In older Grafana the data source proxy meant a Viewer could issue queries of their own choosing through Grafana to the backend, using Grafana’s credentials. Modern versions scope this far better, but the principle holds: a Viewer is a query interface to your monitoring backends, not a static image.

The disclosure is also worth taking seriously on its own. Monitoring data maps internal topology — hostnames, service names, database names, versions, request volumes, deployment timings, which things are unhealthy right now. That is reconnaissance handed over without a login.

If you genuinely need a public dashboard

Do not reach for [auth.anonymous] — it applies to the whole organisation and exposes everything in it. Grafana has purpose-built alternatives that are scoped to one dashboard:

• Public dashboards — a per-dashboard share feature, so exposure is a deliberate choice on a specific dashboard rather than an org-wide setting.
• A dedicated organisation with its own data sources and only the dashboards meant to be public, with anonymous access enabled there. Grafana’s org_name under [auth.anonymous] selects which organisation anonymous users land in, which is what makes this workable.

Either way, hide_version = true is worth setting so the footer stops advertising the exact build to anonymous visitors.

The related setting that is not a default

allow_embedding defaults to false, which blocks Grafana being framed by another site. Turning it on to embed a dashboard elsewhere also removes the clickjacking protection. If you enable it, pair it with a Content Security Policy naming the permitted framing origins — the same reasoning as X-Frame-Options on nginx.

Verify it worked

The definitive test needs no credentials — that is the point:

curl -sS -o /dev/null -w '%{http_code}\n' https://grafana.example.com/api/search

Expect 401. A 200 with a JSON body means anonymous access is on and dashboards are enumerable without logging in.

Confirm what the running config resolved to, including environment overrides:

grep -A4 '^\[auth.anonymous\]' /etc/grafana/grafana.ini
docker inspect grafana --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -i 'GF_AUTH_ANONYMOUS\|GF_USERS'

Remember that no output means the default, which here is the safe value.

Check for public dashboards, which are a separate surface from anonymous auth and will not show up in the config at all:

curl -sS -u "$GF_ADMIN_USER:$GF_ADMIN_PASS" \
  https://grafana.example.com/api/dashboards/public-dashboards

Anything listed there is reachable by URL without a login.

Before you apply this

Turning anonymous access off — the direction this page cares about — breaks whatever was relying on it, immediately and visibly. That is usually a wall display, a status page, or a link circulated internally.

Find out before you flip it:

sudo journalctl -u grafana-server --since '7 days ago' | grep -ci anonymous
sudo grep -rn 'GF_AUTH_ANONYMOUS' /etc /opt /srv --include='*.y*ml' --include='*.env' 2>/dev/null

Have the replacement ready first — a public dashboard for the specific board, or a separate organisation — then disable the org-wide setting. Doing it in that order turns an outage into a migration.

If a wall display is the only consumer, a service account token in a kiosk browser profile is another route, and it keeps the access attributable and revocable.

Restart is required; dashboards and users are in the database and are not affected:

sudo systemctl restart grafana-server

Related

• Change the Grafana admin password — the credential this setting bypasses entirely.
• Restrict data source permissions — what a Viewer can reach through Grafana.