When Grafana anonymous access fits a wall display and when it does not
Anonymous access fits a wall display when every panel on that screen is something you would show to anyone who can reach the instance, and the screen sits on a network segment that outsiders cannot reach. If a team wants an operations screen without logins, apply that test first and enable the feature only if the dashboards pass it. Treat anonymous access as a trade-off you choose and document. In self-hosted Grafana it is set in the [auth.anonymous] section of the configuration file. When enabled, unauthenticated visitors receive one role in one organization, selected with the org_name and org_role keys. Read the Grafana authentication docs for the current options before you rely on the defaults.
The main risk is exposure through the dashboard itself. Anyone who loads the URL sees every panel the anonymous role can read, including series names, host names and query results. If that role can open Explore or change dashboards, the screen also becomes a path toward your data sources. Confirm what the anonymous role can do in your version, then remove every permission the screen does not need. Anonymous access also removes attribution, because activity cannot be tied to a named person. That gap matters if a control in your framework requires individual accountability. Pair the change with the hardening steps in the Grafana security hardening docs, including hiding the version from unauthenticated users and requiring authentication for the metrics endpoint.
Anonymous access does not fit when the screen shows customer records, financial figures, security or incident data, or when the instance is reachable from the internet. In those cases, a dedicated read-only account on a locked kiosk browser keeps the screen inside your normal sign-in controls. A shared account still needs an owner, a password rotation process and a periodic review of what it can see. Licensing belongs in the same decision. The licensing page describes Grafana Enterprise as a non-AGPL commercial option, but it does not settle how anonymous devices are treated. Ask Grafana Labs to confirm those terms in writing before you commit to a design that depends on them.
Which organization and role anonymous users get
A wall display needs to render dashboards and nothing more. The Viewer role gives an anonymous session read access to the dashboards in its organization without permission to save changes, edit panels, run queries from Explore or manage data sources. That keeps a screen in a lobby or operations room from becoming an editing point, even if someone reaches the browser. The anonymous settings are part of the [auth.anonymous] section of the Grafana configuration file, and the organization name and org role are set there as well. Confirm the exact key names and their defaults in the authentication documentation for your Grafana version before you change them.
- Read-only by design: Viewer prevents saving dashboards and editing panels, which limits what a display session can alter.
- Scoped organization: The anonymous session only sees the organization named in the configuration, so keep that organization's dashboards limited to what the screen should show.
- Predictable behavior: A single role for every anonymous device makes it easier to explain what a display can and cannot do during an audit.
- Kiosk-style layouts: Dashboards built for a screen should avoid panels that expose sensitive detail, because anyone who can reach the URL sees the same view.
- Verification step: Open the dashboard URL in a private browser window with no login and confirm that edit controls are absent.
Before go-live, check that the anonymous organization contains only the dashboards intended for display and that the Viewer role is the one assigned to it.
Editor and Admin roles let an unauthenticated session change content, and in the case of Admin, change the organization's settings and users. Assigning either role to anonymous access turns a shared URL into a write path. Even Editor can alter saved dashboards that other users rely on, and changes made from a display would not be tied to any named person. The configuration keys that set the org role for anonymous sessions accept these values, so the choice needs to be a deliberate review item rather than a default. Treat any proposal to raise the role as a change requiring security sign-off.
- Editor access: Anonymous Editors can modify or delete dashboards and panels in the organization, which can break views used by authenticated teams.
- Admin access: An anonymous Admin could change data sources, users and plugins, which is a full control surface for anyone who reaches the instance.
- No individual accountability: Anonymous actions are not attributed to a person, which weakens investigation after an unwanted change.
- Cumulative exposure: Each additional permission adds to the damage a leaked URL or compromised kiosk can cause.
- Review trigger: Record the reason for any role above Viewer, the people who approved it and the date it should be reviewed.
Ask your team to confirm, in writing, that no anonymous role above Viewer is required for the displays in scope.
Anonymous access is granted per organization, so the choice of organization matters as much as the role. Placing anonymous sessions in a dedicated organization keeps displays away from internal dashboards, data sources and teams that other users work in. Authenticated users in other organizations are unaffected by the anonymous setting, but users who belong to the same organization will see the same content, and the anonymous organization should not hold anything they would not want public inside the building. Review how the organization is laid out before you attach any screens to it, and confirm the current behavior of multi-organization handling in the authentication documentation for your version.
- Dedicated organization: Create an organization used only for display dashboards, separate from the one holding operational or customer data.
- Minimal data sources: Connect only the data sources a display needs, and avoid sources that hold credentials or sensitive records.
- No shared membership: Keep authenticated staff out of the display organization unless they need its content, so their permissions do not overlap with anonymous access.
- Dashboard inventory: Keep a list of every dashboard in the anonymous organization and review it when dashboards change.
- Test the boundary: Confirm that anonymous sessions cannot reach dashboards or data sources in other organizations.
When you finish, check that the anonymous organization holds only the approved displays and that no other organization is visible from an anonymous session.
Some teams reach for anonymous access because they want one or two dashboards visible to people outside the instance. Shared dashboards, which give a link to a specific dashboard without a login, can cover that need with a narrower scope than enabling anonymous sessions for a whole organization. Either approach exposes content to whoever holds the link or reaches the instance, so the choice depends on how many views must be public, how long they stay that way, and who must be able to see them. Confirm the sharing options and their behavior in the documentation for your version before deciding.
- Scope of exposure: Anonymous access exposes everything in the organization's role, while a shared link exposes one dashboard.
- Lifetime of access: Review whether a public link should expire or be removed after an event, and confirm how your version manages that.
- Audience: Decide whether the audience is internal users on a shared screen or external viewers outside your network.
- Recovery: Confirm how a shared link or anonymous setting is revoked if the content changes or a screen is lost.
- Documentation: Record which option was chosen, why, and who owns the decision.
Before choosing, write down the dashboards in scope, the audience and the revocation procedure, then confirm the sharing behavior against your Grafana version.
What data anonymous access exposes
Anonymous access removes the login step, so anyone who can reach the Grafana address can see what the anonymous role is allowed to see. The risks below follow the path from URL to dashboard, data source, panel content and server metadata, and each one needs its own control.
Dashboards readable by URL
Any dashboard in an organization that allows anonymous viewing can be opened by anyone who reaches the Grafana address, including people outside your network if the instance is published. Before enabling anonymous access, list every dashboard in the target organization and confirm that each one is safe for an unauthenticated audience. Keep the anonymous organization separate from internal ones so that a new internal dashboard is not exposed by accident. Also confirm that the instance is reachable only from the wall display network.
Data source queries run for anonymous viewers
Panels query your data sources on behalf of the anonymous role, so every refresh sends a query that the server runs with the credentials configured for that data source. A viewer who cannot log in can therefore still cause load on logs, metrics or SQL systems and read whatever those queries return. Review which data sources the anonymous organization can reach, use read-only credentials, and restrict queries to the aggregates the display needs. Confirm how the data source is configured in your environment before relying on this control.
Labels and hostnames in panel output
Metric labels, log lines and table columns often carry hostnames, internal IP addresses, usernames, customer identifiers or build details that were never meant for a public screen. A panel that looks harmless on a wall display can reveal your network layout to anyone who views the page. Check each panel's legend, tooltip and table output, drop or rename sensitive labels in queries, and review log panels for secrets or personal data before they appear in the anonymous view.
Unauthenticated metrics endpoint
Grafana exposes a metrics endpoint that reports internal behavior about the server. The security hardening guidance recommends requiring authentication for this endpoint, so that anonymous visitors cannot read it even when dashboards are open. Confirm the metrics endpoint setting in your configuration, and test from outside the wall display network that the endpoint refuses unauthenticated requests. Scope which network paths can reach it at the load balancer or proxy as well.
Version information visible to visitors
Grafana can reveal its version to unauthenticated users, which tells an attacker which vulnerabilities may apply to your instance. The hardening guidance recommends hiding the version from unauthenticated users, so anonymous visitors see only the interface they need. Check the version setting in your configuration, then compare what a logged-out browser and an unauthenticated API request reveal. Keep the patch schedule in mind, since a hidden version does not replace timely updates.
How to enable anonymous viewing without exposing the wider instance
This sequence limits anonymous access to one dashboard organization on a display network, so a wall screen can show its dashboards without exposing admin pages, Explore or other teams' data. Each step ends with a check you can run before the display goes live.
Choose the dashboards for the display
The operations or platform owner lists the dashboards the screen needs and confirms that each one shows only data that anyone allowed to see the screen may read. Remove panels that expose hostnames, customer identifiers, internal IP ranges or query text you would not show on a public monitor. Done means you have a written list of dashboard names and a sign-off from the data owner for each data source they query.
Create a dedicated organization for the display
A Grafana server administrator creates a new organization that holds only the copied or newly built display dashboards and the data sources they need. Keep the organization's data source permissions narrow so that any panel shown anonymously can be traced to a deliberate choice. Done means the organization exists, contains only the approved dashboards and lists no users other than administrators.
Set the anonymous role to Viewer
In the Grafana configuration file, the administrator enables the
[auth.anonymous]section, sets the organization name to the dedicated display organization and setsorg_roletoViewer. Anonymous users then belong only to that organization with read-only rights. Confirm the exact keys against the authentication documentation for your Grafana version before you apply them. Done means a browser with no session loads the display dashboards and cannot edit them.Restrict network reachability to the display network
The network team limits access to the Grafana port or proxy route so that only the display devices' subnet or VLAN can reach the anonymous URL. Block that route from general corporate networks and the internet, and keep administrative access on a separate path that requires normal login. Done means a test request from an approved display address succeeds and the same request from an unapproved address fails.
Confirm anonymous sessions cannot reach admin or Explore
From a private browser window with no session, the tester opens the server administration pages, the user and organization management pages, Explore and the dashboards of other organizations. Each attempt should be refused or redirected to the login page. Repeat the test with the display URL and the Grafana API endpoints that anonymous users can call. Done means every attempt is blocked and the results are recorded with dates and the Grafana version tested.
Test isolation between organizations
The tester switches a known data source or dashboard in another organization and confirms it is not visible through the anonymous session, including through search, folder listings and direct dashboard links. The test also checks that the display organization's data sources cannot be used to query systems outside that scope. Done means the isolation test passes and the test steps are saved so they can be repeated after each upgrade.
Review the hardening settings
The security owner reviews the Grafana security hardening guidance for this instance, including secure and SameSite cookie settings, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. Anonymous access makes the public surface larger, so each control should be set and recorded. Done means a signed review lists each control, its setting and any exception with a reason.
How Enterprise licensing applies to anonymous devices
The licensing question for anonymous access is not answered by the open-source license alone. The Grafana licensing page sets out how the open-source edition and Grafana Enterprise differ, and Enterprise is offered as a commercial option outside the AGPLv3 terms that apply to Grafana itself. Anonymous viewing is not a feature that the public licensing summary addresses in device terms, so you should not assume that a wall display, a kiosk or a shared browser sits outside Enterprise licensing. Before rollout, ask Grafana Labs in writing whether any anonymous or shared device counts toward Enterprise licensing, and what counting method applies.
Licensing can apply to shared or anonymous use because the license is tied to how the software is deployed and used, not only to named individuals. A dashboard that runs on a dedicated screen with no user identity may still be a device that the vendor counts, and a shared login used across several screens can raise the same question. Write down each planned display, the browser or device it uses, whether it signs in at all, and who owns the account behind it. Those facts are what Grafana Labs will need to answer the question accurately.
Put the answer in the rollout plan before the first screen goes live. Ask for the license terms that cover anonymous and shared devices, the metric used to count them, how changes are reported, and what happens if the count rises after go-live. Ask whether the answer depends on the edition or the deployment model, and whether a shared dashboard link would change the position. Treat the written response as a gate: if the terms are unclear or cost more than the wall display is worth, choose a non-anonymous option such as a shared dashboard or a locked service account.
Questions buyers ask before enabling anonymous Grafana access
Is anonymous Grafana access safe on an internet-facing instance?
In most cases it is not, and an internet-facing instance is the setting to avoid. With anonymous access enabled, anyone who can reach the address can open every dashboard the anonymous role can see, along with the data those panels return from connected sources. The Grafana hardening guidance assumes unauthenticated visitors should learn as little as possible. It recommends hiding the version from them and requiring authentication for the metrics endpoint. For a wall display, the safer pattern is a private network segment, a VPN or an access proxy in front of Grafana, and a written check of which URLs answer without a session. Anything shown to the public should be a deliberate, separate publication, made after someone has reviewed its data.
Can a wall display use a Viewer account instead of anonymous access?
Yes, and a dedicated Viewer account is usually the better design for a display on any network that matters. The screen signs in with a known identity, so its access can be attributed, disabled and limited to the folders it needs. Anonymous access removes that identity from the log trail, which makes it harder to answer who viewed what. The trade-off is operational. A signed-in browser session must survive reboots, network drops and a lobby where people can reach the keyboard. Ask the team to confirm how the screen restores its session after a restart, whether the account password can be rotated without a site visit, and whether the session timeout suits a display that runs all day. Those answers often decide the choice more than the theory does.
What licensing questions should we raise before enabling anonymous access?
Start with which edition and license your deployment falls under, and ask the vendor to confirm in writing how anonymous devices are counted. Grafana's licensing page explains the April 2021 move of Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3, and states that Grafana Enterprise is offered as a non-AGPL commercial option. Open-source use carries its own obligations, which your legal team should read directly. For Enterprise, ask what counts as a device or user, whether a shared screen is one device or several, how the count is measured and what happens when screens are added or replaced. Keep the agreed terms with the deployment record. The engineering team can build the display, but the licensing questions belong to procurement and legal.
How long does a review and rollout take, and what drives the effort?
No fixed duration applies, because the effort follows the size of the review. One display on a private network showing one dashboard folder is a small job. A fleet of screens, several dashboard owners, a public-facing address or an Enterprise licensing review adds work at each step. The main drivers are how many dashboards and data sources the displays touch, whether those sources hold sensitive data, how many Grafana instances and versions are involved, and whether the instance runs on one server or on a high availability pair backed by MySQL or PostgreSQL. Grafana's upgrade guidance describes minor releases every other month and patch releases at least monthly, so the rollout also has to fit a patching routine. DeployOpen engagements are fixed-scope, so the timeline is agreed in writing once the inventory is known. Review the upgrade guidance to plan the patch cadence.
What does our team need to provide before an engagement starts?
Three inputs make the scope concrete: a dashboard inventory, a network design and a named owner for each display. The inventory lists every dashboard and folder the screens would show, the data sources behind each panel and any panel that exposes sensitive fields, such as customer identifiers, patient records or internal hostnames. The network design states where Grafana runs, which addresses can reach it, how the screens connect and whether a proxy or VPN sits in front. The display owner decides what the screen may show, approves changes and receives calls when it fails. Without that owner, anonymous access tends to outlive the reason it was enabled. Also provide the Grafana version, the database in use and the current authentication settings, so the review begins with the running configuration as it is today.
Can our own team set up anonymous Grafana access without a partner?
Yes, a team with Grafana administration experience can make the configuration change itself. The setting lives in the authentication configuration, and the security work around it requires judgment. Internal teams usually handle the configuration change, the dashboard folder design and day-to-day display support well. They often have less time for the exposure review, the licensing questions and the test that confirms which endpoints answer without a session. A partner's work is scoped in writing and can cover the review, the hardening pass, the network changes and the documentation an auditor will ask for. Ask internal staff to walk through the authentication settings, the anonymous role, the metrics endpoint and the reverse proxy, then decide which parts they can own through future upgrades. Retainers cover upgrades and ongoing support if the team wants continuity after the first rollout.
Are shared dashboards a safer alternative to anonymous access?
Often, yes, because a shared dashboard publishes one view on purpose and leaves the instance behind normal sign-in. People who never log in can see that dashboard, while everything else stays protected. Check the limits before choosing it. Shared links expose the dashboard they point to, so the owner must confirm that every panel's query, variables and annotations reveal no more than intended. Links can be copied and forwarded, so treat them as bearer credentials. Rotate or remove them when a display changes, and record who created each link. Public sharing also needs a decision on whether the data is appropriate for outside viewers at all. The security hardening guidance covers the settings that govern exposure, and the sharing options available depend on your Grafana version, which should be confirmed before the design is finalized.
Limits to confirm in your environment
Anonymous access touches four things: the settings your Grafana version actually supports, what sharing features your edition includes, what an anonymous session can query, and what your audit trail can show afterward. Put each question to Grafana Labs or test it on a staging instance before a wall display goes live.
Exact anonymous settings for your version
Anonymous access is controlled through the authentication settings in the Grafana configuration file, including the organization and role that anonymous sessions receive. Option names, defaults and the role choices can change between major releases, so do not copy settings from an older guide. Ask Grafana Labs or check the documentation for your exact version, then confirm on a staging instance that an unauthenticated browser sees only the intended dashboards. Record the version and the settings you tested.
Shared dashboards and public links
Whether your edition offers public or shared dashboard links, and how they behave, is a licensing and configuration question, not an assumption. Some sharing options expose a dashboard without any login, which is a different risk from an anonymous session tied to an organization. Ask which sharing modes exist in your edition, whether they can be disabled centrally, and who in your organization is allowed to create them. Confirm the answer in writing before you rely on it for a wall display.
Data source permissions for anonymous queries
An anonymous session runs queries through the data sources configured for the organization it joins, so it can see whatever those data sources return. Check whether the data source credentials are shared across all users, whether any panel uses a query that returns sensitive fields, and whether template variables expose values such as hostnames or customer identifiers. Test each dashboard as an anonymous user and compare the results with what an authorized viewer sees.
Audit visibility of anonymous activity
Ask what your audit records show when a request is made without signing in. Anonymous views may appear under a generic identity, which makes it hard to tell one screen from another or to trace who viewed a dashboard. Confirm which events are logged in your edition, where logs are sent, how long they are kept, and whether your retention policy meets your own requirements. Write down the gap if anonymous views cannot be attributed.
Enterprise terms for shared devices
Anonymous devices such as wall displays may count differently under Enterprise licensing than named users do. Ask Grafana Labs how a shared or anonymous device is counted, whether a display that is not tied to a person needs its own license, and what the license agreement says about kiosk or public use. Get the answer in writing and keep it with the license record, because an audit or renewal may ask for it.
Exposure of the instance itself
Anonymous access makes the login boundary thinner, so the instance must be reachable only on the networks you intend. Check that the version and metrics endpoints require authentication, that cookies and headers follow the hardening guidance, and that the server is not exposed to the internet by accident. Scan the instance from outside your network to confirm what an unauthenticated visitor can reach.
A decision checklist before any anonymous screen goes live
Start with the question that decides everything else: what would an anonymous viewer be able to see? Before any wall display is switched on, list every dashboard and panel it would load and check each data source behind them. A panel that shows only aggregate uptime is a different risk from one that shows hostnames, internal IP addresses, customer identifiers or log lines with request details. Anonymous access is granted per organization, and the role it assigns applies to everything in that organization, so a dashboard that is harmless alone can become sensitive once it sits next to one that is not. If the dashboards would not be acceptable on a public web page, they should not be shown to an unauthenticated browser either, and the shared dashboard options covered elsewhere on this page are usually the better fit.
Next, confirm the network path and the licensing position in writing. The screen should sit on a segment that only the monitoring room can reach, with the Grafana endpoint kept off the internet and the firewall rules reviewed by the team that owns them. Network isolation does not remove the need to check licensing. Ask Grafana Labs how anonymous devices are counted under your agreement, and read the current terms on the Grafana Labs licensing page rather than relying on an older summary. Record the answer, the person who gave it, and the date, so that an audit or a future edition change does not start from memory. Also confirm the open-source edition behavior for your exact version, because the anonymous role and organization settings are documented in the configuration reference and should be checked against the release you run.
Then plan how you will watch and reverse the change. Decide which events you need to see for anonymous sessions, whether that is login activity in the Grafana logs, unexpected requests to the endpoint from outside the monitoring subnet, or changes to the anonymous settings in the configuration file. Assign an owner to review them. Write a rollback plan that names the configuration change that disables anonymous access, who can make it, and how long a restart takes in your environment, and test it on a non-production instance first. The recommended pattern is conditional: approve anonymous access for a named set of low-sensitivity dashboards, on an isolated network, with a confirmed licensing answer, a logging owner and a tested rollback. Where any one of those conditions is missing, use an authenticated kiosk account or a shared dashboard link instead.
