Limiting Grafana snapshot and shared dashboard exposure

Limiting data exposure from Grafana snapshots and shared dashboards starts with knowing what leaves the instance

Sharing features can publish Grafana data outside the instance, so they need to be governed deliberately rather than left at their defaults. A shared, self-hosted Grafana that holds sensitive operational data can leak through four paths: external snapshots, which copy a dashboard's rendered data to a publicly reachable snapshot server, externally shared dashboards, which give anyone with a link read access to a live dashboard, annotations, which can carry free-text notes and event data into those shared views, and anonymous access, which lets visitors view dashboards without signing in. Each path exposes different things. A snapshot freezes values at the moment it was taken, a public dashboard keeps reflecting current data, and anonymous access widens the audience for everything the anonymous role can see.

Teams usually need this control in three situations: when the underlying data is regulated or confidential, when operations dashboards are shared across business units or with a vendor, and when an external party such as an auditor or managed service provider asks for a view of operational state. In each case the decision is which dashboards may leave the instance, who approves that, and which settings enforce the decision. This page covers the behaviour of self-hosted open-source Grafana. Setting names, defaults and the exact sharing options differ between releases, so confirm each key and its default against the Grafana version you run, using the Grafana security hardening documentation as the starting point.

Which sharing paths can move data out of Grafana

A snapshot stores the rendered results of a dashboard at a moment in time, so someone can open a link without a live connection to the data source. When snapshots are published externally, the stored copy sits on a service outside your network. Who can trigger this depends on the server setting that allows external publishing, so the control belongs to the administrator who sets that option, and editors with snapshot rights carry the risk.

What it carries: the query results behind each panel at capture time, including series labels, hostnames, tenant names and any values the panel displays. Those values can be visible to a viewer who would not normally have access to the source system.
Who triggers it: users who can share a dashboard as a snapshot, typically editors, once external publishing is enabled in the [snapshots] section of grafana.ini.
Retention and deletion: the copy outlives the dashboard. Your retention, access logging and deletion controls may not reach data stored by an external service.
Risk in regulated environments: operational or personal data leaves your infrastructure without the controls that cover the source system, and a link can remain valid after the people who created it no longer need it.
Local alternative: internal snapshots keep the copy on your instance, but they still hold panel data and need expiry rules.

Check the effective value of the external setting on every instance, including staging copies restored from production, and confirm the default in your version's configuration reference.

Anonymous access lets a visitor view dashboards without signing in, using the organization and role the server assigns to anonymous users. It is a server-wide setting in the [auth.anonymous] section, so one change affects every dashboard that the anonymous role can reach. Unlike a public link, it is not limited to dashboards someone chose to share, which makes it the broadest path in this section.

What it carries: any dashboard, panel result and annotation that the anonymous role can read in its assigned organization.
Who triggers it: no individual request is needed. An administrator enables it, and anyone who can reach the instance can then view its content.
Related exposure: the version and the metrics endpoint can reveal internal details to unauthenticated users. The Grafana security hardening guidance recommends hiding the version and requiring authentication for the metrics endpoint.
Risk in regulated environments: anonymous viewers sit outside your identity provider, so access reviews and user-level audit records cannot tie a view to a person.
Verification: test the instance from a clean browser session outside your network to confirm what an anonymous visitor can reach.

Confirm that anonymous access is disabled for production instances, and record the setting and the test result as evidence for your access review.

Sharing settings and when to turn each one off

This table lists the Grafana settings that govern what leaves an instance through sharing features, what each one controls, when keeping it fits, and when to disable it. Read each row against your data classification, and confirm exact configuration keys and defaults in the Grafana docs for your version before changing anything.

Control	What it governs	Keep it when	Turn it off when
External snapshot publishing	Lets a user push a dashboard snapshot, including its rendered data, to an external snapshot service so others can open it without signing in	Snapshot content is limited to non-sensitive data and you run or trust the snapshot target	Panels query production data, labels or log lines contain customer or personal data, or your network policy forbids outbound publishing
Local snapshots	Keeps snapshots inside your own Grafana instance, visible only to users who can already access it	Teams need short-lived sharing inside the organization and snapshot expiry is set	Snapshots must be restricted by role or the instance is shared with parties outside the organization
Externally shared dashboards (public dashboards)	Publishes a dashboard at a public link that anyone with the URL can view, with no Grafana login	The dashboard shows only data approved for public release and time ranges and variables are reviewed	Dashboards query internal data sources, use template variables that expose hostnames or tenants, or no owner reviews publication
Annotation handling on shared dashboards	Determines whether annotations, and the query results behind them, are included when a dashboard is shared externally	Annotations contain only generic event names with no internal identifiers	Annotations carry deployment details, ticket numbers, user names or incident text
Anonymous access	Lets unauthenticated visitors reach Grafana with a chosen organization role, usually Viewer	A read-only status page is intended and only non-sensitive dashboards are in that organization	Any dashboard or data source in the instance could hold internal data, which is the usual default for shared internal instances
Public dashboard and sharing feature switches	Enables or disables the sharing features at instance level, so individual users cannot publish links	Publishing is a governed activity with named owners and a review step	No external sharing is required, in which case disable the feature and confirm that existing links are revoked
Authentication requirement for the metrics endpoint	Controls whether unauthenticated callers can read Grafana's own metrics	Monitoring systems authenticate and the endpoint is reachable only from monitoring networks	The endpoint is exposed to untrusted networks, since it can reveal operational detail

How to lock down sharing on a self-hosted Grafana instance

This sequence finds every existing share, turns off the sharing paths you do not need, and proves from an unauthenticated client that data no longer leaves Grafana by those routes. Each step ends with a check, so the result is evidence rather than an assumption.

Inventory existing shares and anonymous access
The Grafana administrator lists every dashboard with public sharing enabled, every snapshot that was published externally, and the current anonymous access setting. For each item, record the owner, the data sources and annotations it draws on, and whether anyone still needs it. Confirm the anonymous access setting in the configuration file and in the server administration view, since the two can disagree after manual changes. The step is done when you have a written inventory with an owner for each item and no unreviewed external links.
Disable external snapshot publishing
Set the external snapshot option to false in the snapshots section of the Grafana configuration file, then restart the service through your normal change process. Keep the change in the same version-controlled file or provisioning source as the rest of your settings. Confirm the configuration key name against the Grafana docs for your installed version before you change it. The check is that the publish option no longer appears for users, and that an attempt to create an external snapshot, made both signed in and with the API, is refused.
Turn off anonymous access and public dashboards
Set the anonymous authentication section to disabled so that no session can be created without signing in. Then review the public dashboard settings for your version and turn off public sharing if your organization does not need it. Confirm the exact keys and their defaults in the Grafana configuration reference for your release, because these settings have changed across versions. The check is done in a fresh browser with no session: dashboard URLs should redirect to sign-in, and former public dashboard links should stop returning data.
Review annotations on externally shared dashboards
For each dashboard that must stay shared, open its annotation queries and the panels that show annotation data. Look for hostnames, internal ticket references, incident descriptions, employee names and customer identifiers that would be visible to anyone with the link. Remove or narrow the annotation queries that carry such data, and confirm that panel titles and tooltips do not expose it either. Because shared views can show annotation content, treat this as a content review, not only a settings change. The check is a visit to each shared link from an outside client, confirming that only the intended annotations and values appear.
Restrict which roles can share
Using the folder and dashboard permissions in your edition, limit the sharing and publishing actions to a named group of owners, and remove them from general Editor roles on sensitive folders. Where dashboards are defined in provisioning files, make the sharing setting part of the reviewed change rather than something people toggle in the interface. Confirm how your edition and version expose these permissions before you rely on them. The check is a test account in each role, with a Viewer unable to find a share action and an Editor outside the approved group unable to publish on a restricted folder.
Verify each sharing path from an unauthenticated client
From a machine outside your trusted network with no cookies or tokens, repeat every test: the snapshot links from the inventory, the public dashboard links, the anonymous sign-in route and the relevant API endpoints. Record the request, the response and the time of each test in an evidence file. Repeat the same tests after every configuration change, after each Grafana patch, and after any upgrade, because sharing defaults can change between releases. The step is done when every path returns a refusal or sign-in redirect and the evidence file is filed with the change record. The Grafana security hardening guidance is a useful companion for the wider settings to review.

Security and operational risks to manage after the controls are set

Turning off snapshot publishing and anonymous access reduces exposure, but it does not clear what has already left Grafana or what the remaining roles can still share. The cards below cover the residual risks that remain after the settings are changed, and the checks that connect those settings to the wider hardening guidance.

Published snapshots stay reachable

A snapshot pushed to an external snapshot service remains viewable by anyone holding its link until someone deletes it. Disabling external snapshots stops new publishing but does not remove existing ones. Before the change, list snapshots already published, delete the ones that contain sensitive panels, and confirm with the snapshot provider how deletion works on their side. Check that the delete key was retained for each snapshot you intend to remove.

Shared links cached by third parties

A public dashboard link can be copied into chat tools, ticket systems, search indexes or browser caches, and those copies outlive the sharing setting. Revoking the link in Grafana cuts off direct access, but it does not recall copies that were already fetched. Treat any panel that was public for a period as exposed, review what data it showed during that window, and ask your team to confirm how link revocation is logged so the window can be bounded.

Broad share rights from role mapping

Share permissions follow the role an identity receives, so an identity provider group mapped to Editor or Admin may be able to publish dashboards externally without anyone deciding that it should. Review each role mapping and confirm which roles can create public links or snapshots. Limit those rights to a named group, and check the mapping after every change to group membership rules in your identity provider.

Sensitive text in annotations

Annotations are stored with the dashboard and can appear on panels shared externally, so a note such as an incident ticket, customer name or internal hostname can leak even when queries are hidden. Review annotation sources, including any that come from data sources or automation, and decide which annotation text may appear on a shared view. Where annotations are needed on public views, keep their content generic and confirm the behaviour in your Grafana version.

Metrics endpoint left open

Sharing controls only cover dashboards, while the metrics endpoint exposes internal state and version information to whoever can reach it. The hardening guidance recommends requiring authentication for the metrics endpoint and hiding the version from unauthenticated users. Confirm both settings in your configuration file, and test from outside your network that the metrics endpoint and login pages do not return data without credentials.

Settings drift after upgrades

Sharing options are configured in the server configuration file and sometimes change defaults between releases, so a setting that worked last quarter may not hold after an upgrade. Store the sharing and anonymous access settings in version-controlled configuration, rerun the checks after each patch release, and include them in your review of the upgrade notes before rollout.

How snapshots and public dashboards differ in what they keep

A snapshot stores a copy of the data behind each panel at the moment it is created, so the exposure is fixed in time. A shared dashboard, by contrast, keeps no copy of its data. When someone opens a publicly shared dashboard, Grafana runs the panel queries again against the configured data sources and renders the current results. That difference determines what an outsider can see and for how long. A snapshot shows what was on screen on the day it was taken, and it remains visible until someone deletes it. A public dashboard shows whatever the underlying query returns at the moment of viewing, so the exposure lasts as long as the sharing link stays active and the queried series keep returning data.

The practical consequence is that the two features need different reviews. For a snapshot, the question is what the panel queries returned when the snapshot was taken, including labels, hostnames, customer identifiers, error messages and any values embedded in panel titles or annotations. For a public dashboard, the question is which data sources and queries sit behind the panels, and whether a viewer could change a time range or variable to reach more data than the panel was meant to show. Confirm in the Grafana docs for your exact version how snapshots are stored (whether data is kept inside Grafana or sent to an external service), how long they persist, and which data a public dashboard can reach, because these behaviours have changed between releases and differ by configuration.

Before you allow either feature, write down which dashboards may leave the instance, who may create the link, and what the owner must check before publishing. Treat a snapshot as a data export that needs the same approval as any other extract from production telemetry. Treat a public dashboard as a standing query endpoint that needs its own data source review. Ask your team to test each candidate dashboard from a logged-out browser session and to confirm which panels, series and annotations appear there, since that test shows the exposure more reliably than the dashboard's own settings page.

Questions teams ask before changing Grafana sharing settings

How much does a Grafana sharing lockdown cost and what drives it?

Cost follows the written scope, and DeployOpen does not publish a price list, so a quote is built from the scope you agree. The main drivers are the number of Grafana instances, folders and dashboards that use sharing, whether external snapshots or public dashboards already exist, and how much evidence the review must produce. Most of the cost is one-time work: inventory, settings changes, verification and a handover document. Recurring cost appears only if you add a retainer for monitoring or patch checks. Ask the quote to show labor separately from any licensed software, and ask what triggers a change order if the inventory turns up more shared content than expected.

How long does a review and lockdown of Grafana sharing take?

No fixed duration applies, because the time depends on how many instances exist, how many dashboards are shared and how many owners must confirm changes. A review usually runs in phases: an inventory of what is shared today, a decision on which sharing features stay enabled, a change window for the settings, and a check that outside links no longer resolve. A small instance with one owner moves quickly. An instance with many folders and older external snapshots takes longer, because each owner has to review what was published. Ask for the phases, the owner sign-offs and the change calendar dependencies in writing before work starts.

What must our team provide before a Grafana sharing review?

Your team should provide three inputs before work starts:

A role inventory showing who holds Admin, Editor and Viewer roles, and which team owns each folder.
A dashboard and snapshot list, including dashboards with public links and panels that query sensitive data sources.
A change window agreed with operations, with a named approver and a rollback step.

Also provide the current configuration file or Helm values, so the sharing and anonymous access settings can be read directly. Confirm which Grafana version runs in each environment, because settings and defaults can differ between releases. A named contact from each dashboard owning team speeds up the decisions on which links to keep.

Can our in-house team review Grafana sharing settings themselves?

Yes, a team with Grafana administration experience can review sharing settings internally, and many do. The work is mostly reading configuration, mapping roles and asking dashboard owners whether each shared link is still needed. What is harder for in-house staff is independent verification: confirming from outside the network that anonymous access, external snapshots and public dashboards are actually closed, and documenting that result for an auditor. Check whether the team has time to run the inventory with owners, and whether someone outside the admin group can test the outcome. The Grafana security hardening documentation is a useful checklist of settings to confirm against your version.

Does a partner add value beyond changing Grafana sharing settings?

A partner adds value mainly through an outside view of exposure and through written evidence. DeployOpen plans, implements, hardens and documents self-hosted platforms inside the client's own infrastructure, and runs security testing that can include a check of sharing features. A tester can probe the instance from an unauthenticated position, then retest after the changes are made. Be clear about the limit: DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so your auditor still decides conformance. Ask for the test scope, who signs off the findings and what retesting the fixed scope includes.

What breaks when Grafana anonymous access or external sharing is disabled?

The usual breakages are external links in tickets, wiki pages and chat that stop loading, embedded dashboards on other sites that show a login prompt, and scripts or automation that call snapshot or public endpoints. Start by searching documentation, runbooks and alert notification templates for existing public links and snapshot URLs, because alert messages often carry dashboard links that lose access after a change. Agree with owners which links to replace with internal dashboard links, and tell on-call staff before the change window. After the change, test the alert notifications that carry links, and keep a rollback step ready in the change record.

How do we keep sharing settings locked after Grafana upgrades?

Treat the sharing settings as part of every upgrade and patch checklist, because a new release may change defaults or configuration keys. Grafana's upgrade guidance describes minor releases every other month and patch releases at least monthly, so a recheck after each patch is a practical habit. After each upgrade, confirm the settings in configuration, rerun the unauthenticated access check and look for newly created snapshots or public dashboards. Record the Grafana version and the result of each check. Ask your internal team or partner to add these steps to the patch runbook, so the recheck runs as routine work rather than a separate project.

What to confirm in your environment before relying on these controls

Sharing controls only protect data if the settings in force on your instance match what you intend. The checks below connect the configuration itself, the way provisioning reapplies it, the edition you run, the snapshots already published and the evidence an assessor will ask for.

Exact settings in your version

Sharing and anonymous access options are named and defaulted per release, so confirm each key against the configuration reference for the exact Grafana version you run, not an older guide. Check the external snapshot setting, the public dashboard and anonymous access switches, and whether the security hardening recommendations have been applied. Record the effective value on a running node, since a file on disk may not be the value in force.

Provisioning overrides runtime changes

If dashboards or data sources are provisioned from files, an administrator who turns off sharing in the UI may see the change revert on restart or reload. Confirm which settings come from grafana.ini or environment variables, which dashboards are loaded from provisioning, and whether your as-code pipeline would reintroduce a shared link. Test a change in a non-production instance and confirm it persists after a restart.

Controls by edition

Not every access or audit control is available in every edition. Confirm with Grafana Labs which sharing and access options apply to the open-source build you deploy, and which sit behind Enterprise or Cloud licensing. The licensing page sets out the editions, so decide early whether a control you need depends on a commercial license before you design around it.

Deleting existing snapshots

Turning off external snapshot publishing does not remove snapshots that were already created. Inventory existing snapshots and public dashboards in each organization, confirm who can delete them, and check whether deletion removes the data held on the external service. Decide how long a snapshot may remain available and document the removal step, including how a deleted link is treated by the external host.

Evidence an assessor expects

Auditors may ask for proof that sharing is restricted, not just a statement that it is. Ask your assessor or certification body which artifacts they accept, such as exported configuration, provisioning files under version control, or periodic screenshots of effective settings. DeployOpen prepares systems and evidence for assessments, but the assessor decides what is sufficient for your framework.

How to show a reviewer that sharing is controlled

A reviewer will accept that sharing is controlled only when you can show the current state of every sharing path and how it has been kept that way. Start by exporting the configuration state of the instance: the effective values of the sharing and anonymous access settings, including the external snapshot and public dashboard options, and the file that holds them. Keep that export with the date, the Grafana version and the name of the person who ran it, so the reviewer can see what was true at a point in time. Store it in your evidence repository alongside the change records for each setting you altered.

Next, build two inventories. The first lists every dashboard that is shared externally or publicly, with its owner, the data sources it queries and the business reason for sharing. The second lists every snapshot that still exists, its creator, creation date and expiry, and whether it was published to an external snapshot service. Pair these with a role assignment export that shows who holds Admin and Editor rights in each organization and folder, and which accounts are service or shared logins. Reviewers often ask who can enable sharing, so record that permission explicitly. Refresh both inventories on a schedule you define and keep the dated copies.

DeployOpen prepares this evidence as part of the implementation, including the export scripts, inventory templates and the change log that links each setting to its approval. Independent auditors or certification bodies make any assessment of whether your controls are adequate, and they may test the evidence in ways we do not control. Confirm with your assessor which formats, retention periods and sampling methods they expect before you collect anything, because a clean export that does not match their request will still slow the review.

How DeployOpen scopes and delivers sharing controls for Grafana

DeployOpen approaches limiting data exposure from Grafana snapshots and shared dashboards as a written, fixed-scope piece of work inside infrastructure you control. We start by inventorying where dashboards, snapshots and anonymous access are used today, then change the settings and operating rules that govern them and document the result for your security and compliance teams.

How we scope

We inventory existing dashboards, public links, snapshots and anonymous access before proposing any change.
The written scope names which sharing features stay enabled, which are disabled, and who approves exceptions.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure external snapshot and shared dashboard settings in the Grafana configuration you control, and test each setting.
We review annotation content on shared dashboards so that internal hostnames, tokens or customer identifiers do not reach external viewers.
We check the results against the Grafana security hardening settings and record any deviation with its reason.

How we hand over

You receive the configuration changes, a settings register and a test log showing how each sharing path was verified.
We document the approval process for creating new public or external shares, with named owners on your side.
Operating runbooks explain how to review existing shares, revoke links and respond if data was exposed.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Retesting after Grafana upgrades confirms that sharing settings still behave as documented.
Your team keeps ownership of the decisions on what may leave the organization, and we record those decisions in the register.