Why Grafana plugin signatures decide what runs on your instance
Grafana plugins run inside the Grafana server or in the user's browser, so a plugin you install can read the data sources you connect and the users who open its panels. Plugin signatures are how Grafana checks where a plugin came from and whether it has been altered before it loads, and that check is the main control between a useful extension and code you never reviewed. Your team faces this decision whenever someone asks for a new data source, an internal panel, an older Angular panel or a community plugin that is not on the default path.
These requests come up more often than most platform teams expect. A new data source for a vendor your engineers already use, a custom panel built by another team, or a community visualization that a dashboard author found on a forum can each arrive with a request to make it work now. Each one changes what runs on a shared instance that may hold credentials for logs, metrics, databases and cloud accounts. The decision should be made once, in writing, before a plugin reaches production, not during an incident when someone needs a dashboard by morning.
This topic covers the signature levels and statuses Grafana reports, why unsigned plugins are blocked by default, what the allow_loading_unsigned_plugins setting changes, and a review process for community and internal plugins. Before you read further, confirm which plugins are installed on your current instances and which ones your teams depend on, because the review effort depends on that inventory. Check the signature status Grafana reports for each one against the current Grafana plugin documentation for your version.
What can go wrong when unsigned plugins load
An unsigned plugin runs code that nobody has verified against a known publisher, inside a process that holds your data source credentials and reaches your users. The cards below cover the main ways that trust gap turns into operational, security and audit problems.
Code execution with server privileges
Backend plugins run as a process on the Grafana server, under the account that runs Grafana. Any code in that plugin can read files the Grafana process can read, open network connections the server can reach, and start other processes. Check which account runs Grafana, whether it can reach internal networks and metadata services, and whether the plugin's backend binary is one you can trace to a reviewed source build.
Exposure of data source credentials
Grafana holds passwords, tokens and API keys for every data source it queries. A plugin that can read the data source configuration or the proxy path can take those credentials and use them outside Grafana. Review which data sources a plugin can reach and use dedicated, read-only credentials for each data source so that a compromised plugin has limited value.
Browser code reaching user sessions
Frontend plugins run JavaScript in the browser of every user who opens a dashboard that uses them. That code shares the page context with the Grafana session, so it can call Grafana APIs as the signed-in user, including users with editor or admin rights. Test what a plugin does in a session with an administrator account before it reaches production.
Abandoned or unmaintained plugins
A plugin can stop receiving fixes while Grafana itself keeps moving through its release cadence. An old plugin may break after a Grafana upgrade or keep a vulnerable dependency that nobody patches. Record the last release date, the supported Grafana versions and the maintainer's response history before you approve it, and set a review date for each plugin.
Supply chain changes between versions
A plugin version you tested can be replaced by a different build with new code, new dependencies or a new maintainer. Without a signature check or a pinned artifact, an automatic update or a reinstall can change what runs without any review. Pin plugin versions in your provisioning or image build, and compare checksums and changelogs before each update.
Weaker audit evidence
When an unreviewed plugin changes data or behaves unexpectedly, you need to show which version ran, who installed it and when it was approved. If plugins are installed by hand on the server, that record may not exist. Keep plugin versions in version-controlled configuration and retain install and approval records, since open-source Grafana does not provide a complete audit log of plugin installs.
Plugin trust options and when each fits
This table compares four ways to decide which Grafana plugins load, from Grafana-signed only to disallowing unsigned plugins entirely. Read each row for the trade-off, the ongoing operator effort and the situation where that option fits. The main takeaway is that loosening trust is a standing decision you must review, and allow_loading_unsigned_plugins should stay narrow.
| Option | Trade-off | Operator effort | When it fits |
|---|---|---|---|
| Grafana-signed plugins only | Narrowest supply chain, but limits you to plugins Grafana Labs signs | Low: mostly confirming plugin versions during upgrades | Shared production instances with strict change control and few plugin needs |
| Private-signed plugins built by your team | Lets internal panels and data sources load, and puts signing keys under your control | Medium: build pipeline, key custody and re-signing on each release | Internal systems with custom plugins that your own engineers build and maintain |
| Specific unsigned plugins by ID | Allows named community plugins through allow_loading_unsigned_plugins, which accepts plugin IDs, but each one bypasses signature checks | Medium to high: review each ID, record the owner and recheck it on every upgrade | A short, approved list for a single plugin your team has reviewed and accepted the risk of |
| Disallow unsigned plugins entirely | Blocks community and unreviewed code, but may stop a dashboard that depends on a missing plugin | Low ongoing, higher during migration when plugins are replaced or removed | Regulated or high-exposure environments where any unreviewed code is unacceptable |
| Broad allow_loading_unsigned_plugins use | Opens every unsigned plugin on the instance, so one malicious or abandoned plugin can run with full access | High: you must track all plugins and their maintainers indefinitely | Generally avoid. Confirm the current setting behavior in the Grafana docs before any change |
How to review and approve a community plugin
This sequence turns an informal plugin request into a documented decision. It records what is installed, checks how each plugin is signed and what it can access, and produces a configuration that can be reproduced and re-reviewed on every update.
Inventory every installed plugin
The platform owner lists the plugins on each instance, using the plugin list in the Grafana interface or on the server and the provisioning files that declare them. For each plugin, record its plugin ID, publisher, installed version, license and source repository. Compare the list against what the provisioning files declare, because a plugin installed by hand that no file mentions is the first thing to explain. Done when every plugin on production has one owner-approved row in the inventory and any unexplained plugin is flagged.
Check signature level and status
For each plugin, the reviewer reads the signature level and status shown on its plugin page and in the plugin metadata, then notes what that status means in the Grafana plugin documentation for the version you run. Confirm whether the publisher is Grafana Labs, a verified partner or a community author, and whether the signature covers this exact version. Record the result in the inventory row. Done when each plugin has a written signature status and any unsigned or unexpected status has a named owner who accepts the risk or removes the plugin.
Review code and dependencies in a non-production instance
A security engineer reads the source at the exact tag or commit being installed, checks the maintainer history and open issues, and reviews the dependency manifest for packages with known weaknesses. They install the plugin on a non-production instance built from the same configuration as production, and watch outbound network calls and the plugin's requests during startup and normal use. Done when the reviewer has a written note covering code findings, dependency results and observed network behavior, with any open item assigned.
Test queries, permissions and data exposure
The reviewer runs the queries and panels the business needs against test data, then checks which data sources the plugin can reach and which users can see its output. They confirm that role-based access in Grafana limits the plugin's views and that credentials used by the plugin are scoped to read-only access where the data source allows it. Test with a non-admin account and a user from each role that will use the plugin. Done when the test record lists each query tested, each role tried and any access that was broader than intended.
Set plugin configuration through provisioning
The platform team adds the approved plugin to the provisioning files, pins the version and sets its configuration there rather than through the UI, so the setting is recorded in version control and reproduced on rebuild. Plugin installation settings, including any setting that allows unsigned plugins, go into the same reviewed change. Confirm that allow_loading_unsigned_plugins is not enabled for plugins that did not pass review. Done when a fresh instance built from the repository loads the approved plugin at the pinned version and the configuration diff is attached to the change request.
Approve the change in change control
The change owner submits the inventory row, signature status, review notes, test record and configuration diff to the change board or the equivalent approval process your organization uses. The approver confirms the business owner, the data each plugin can reach and the rollback step, which is removing the provisioning entry and redeploying. Done when the approval is recorded with the reviewer's name, the approver's name, the date and the exact plugin version, and the change is deployed to production.
Schedule re-review on every update
Each new plugin version is treated as a new change. The reviewer repeats the signature check, compares the new source against the reviewed version, and reruns the tests that covered data access and permissions. The team also watches the Grafana security advisories and plugin release notes, since a plugin can be affected by a platform issue. Done when the inventory shows the review date and approved version for every plugin, and any plugin that has not been re-reviewed after an update is marked as unapproved until the review is complete.
Controls that reduce plugin risk beyond signatures
A plugin signature tells you who packaged a plugin, not whether its code or data access suits your environment. The controls below sit around signatures so that every plugin your instance loads has been chosen, reviewed and tested before it reaches users.
Keep plugins in provisioning
Declare the plugins your instance should run in provisioning files and store those files in version control. A plugin then appears in a reviewed commit rather than through a manual install in the UI, and a rollback is a revert. Check that the provisioning files pin the plugin versions you reviewed, not just the plugin IDs, so a later install cannot change what runs without a change record.
Restrict who can install plugins
Plugin installation should be limited to a small administrator group. Any user who can install a plugin can add code that runs inside your Grafana server or browser. Confirm which roles can reach the plugin catalog in your instance, remove that permission from shared or service accounts, and log who installs or updates plugins in your change process.
Run a staging instance first
Install and test every new or updated plugin on a staging Grafana that mirrors production data sources and user roles before production. Check that dashboards still render, that queries return expected results and that error logs stay clean. Staging also gives you a place to see how a plugin behaves when you move to a newer Grafana minor release.
Limit plugin data source access
Review what each plugin can reach: the data source it queries, the credentials it holds and the network endpoints it calls. Give plugin-backed data sources read-only accounts scoped to the datasets they need, and avoid storing broad administrative tokens in them. A plugin that only needs one database should not have a connection to every system in your estate.
Watch plugin updates with Grafana patches
Grafana patch releases arrive at least monthly according to Grafana's upgrade guidance, so schedule a plugin review alongside each one. Compare the plugin version notes and changelog against your approved register, and check that the plugin still supports the Grafana version you run. A plugin left behind by a Grafana upgrade can break dashboards or stop loading.
Keep an approved plugin register
Maintain a short register listing each approved plugin, its publisher, signature level, version, the data sources it touches, the reviewer and the review date. Require a new entry before any plugin reaches production. A signature alone does not replace this review, because it does not show what the plugin does with your data. Reviewers should read the source or vendor documentation before approving.
Questions teams ask before approving Grafana plugins
What does allow_loading_unsigned_plugins do in Grafana?
It is a setting in the [plugins] section of grafana.ini that lets Grafana load plugins without a valid signature. By default, Grafana checks each plugin's signature before loading it, and an unsigned plugin is blocked. Turning the setting on, or listing specific plugin IDs in it, removes that check for the plugins it covers. Once loaded, a plugin can read the data it is allowed to reach and send requests to the data sources you connected, so the setting widens what untrusted code can touch. Confirm the exact key format and the allowed-list option against the current Grafana plugin configuration reference for your version before you change anything in production.
Is an unsigned private plugin safe to run?
It can be run safely, but the signature check is only one control, and a private plugin needs its own controls. A plugin your team wrote and builds from source in a controlled pipeline has known provenance, so the main risks shift to who can change the code, what dependencies it pulls in and how the artifact reaches the server. Keep the exception narrow by allowing only that plugin ID, not every unsigned plugin. Also check whether the plugin makes outbound network calls, handles data source credentials, and runs on an instance that is reachable from the internet. Ask your engineers to confirm the private signing options for your Grafana version, since signing for private use is a separate workflow from public signing.
How long does a community plugin review take?
No review duration is fixed by Grafana or by DeployOpen, so the honest answer depends on scope. The main drivers are the number of plugins, whether each one has a backend component or is frontend only, and whether source code is available for reading. Each plugin's dependency tree, its outbound network behavior and its handling of data source credentials add time. Testing against a staging Grafana that matches production, and repeating the work for each Grafana version you plan to run, add more. Ask for the expected timeline in the written scope, with the plugin list, the review depth and the environments named, so you can compare the estimate with your own capacity.
Can our own team run the plugin review internally?
Yes, if you have engineers who can read the plugin's language (typically TypeScript or JavaScript for frontend code and Go for backend code), a staging Grafana that matches production, and a written approval rule. Internal teams most often miss transitive dependencies, outbound calls made at runtime, and changes between versions. A workable internal process has four parts:
- A list of approved plugins with the owner, version and business reason for each.
- A code and dependency review step, with a record of what was checked.
- A behavior test in staging that watches network calls and data source access.
- A re-review rule for every plugin update and every Grafana minor release.
If your team lacks Go or frontend review skills, a partner can cover those reviews while your team keeps approval authority.
What do we need to provide if a partner reviews our plugins?
A partner needs enough information to scope the review and enough access to test it. Prepare these items before the first scoping call:
- An inventory of installed plugins, with IDs, versions, publishers and the Grafana version each one runs on.
- The business reason for each plugin and the teams that rely on it.
- The data sources each plugin would reach, and whether it uses shared or per-user credentials.
- Source code or artifact access for private plugins, and the repositories used for public ones.
- A staging environment or a configuration copy with secrets removed.
- A named decision owner who can approve or reject findings.
DeployOpen plans and delivers this kind of work under a fixed scope agreed in writing before work starts, so a complete inventory helps produce a firm quote.
How do plugin updates fit into the Grafana upgrade cycle?
Plugin updates should follow Grafana's release rhythm rather than run on their own schedule. Grafana's upgrade guidance says major releases come once a year in April or May, minor releases roughly every other month, and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. In practice, pin your approved plugin versions, re-test them whenever you move to a new Grafana minor or major release, and apply plugin updates in the same change window as the Grafana patch. Re-review any plugin whose publisher changed ownership or whose dependencies changed, even if the version number looks minor. Read the upgrade guidance with your engineers before setting the window.
What does a plugin review quote depend on?
A quote depends on the written scope, so the cost drivers are the same ones you would plan for internally. Ask for the price to be broken into these components, so you can see who is paid for what:
- Number of plugins and whether each has a backend component.
- Review depth, from a source and dependency read to a full behavior test in staging.
- Number of Grafana versions the approval must cover.
- Whether the work includes private plugin signing, pipeline integration or documentation for your approval process.
- One-time review work versus a recurring retainer for re-review after each plugin or Grafana update.
DeployOpen does not publish a price list. A quote follows from the agreed scope, so the more complete your plugin inventory and environment details are, the more precise the quote can be.
Limits to confirm in your environment
Plugin trust depends on details that change with Grafana version, edition and deployment method. The items below are the points to verify with the vendor documentation and your own environment before a plugin reaches production, because a wrong assumption about any one of them can silently change what loads.
Signature levels and status labels
Confirm the exact signature level names and status labels that your Grafana version reports for each installed plugin. Labels for private, community and Grafana-signed plugins have changed between releases, so a runbook that quotes old wording will send reviewers to the wrong decision. Check the plugin details page and the plugin catalog on the exact build you run, and record the version next to each approval.
Enterprise edition plugin policy
Confirm whether your edition or license changes how plugins are signed, installed, allowed or supported. The open-source and Enterprise editions differ in several access and administration features, so do not assume that a policy written for one applies to the other. Ask your Grafana Labs contact to state in writing which plugin controls are included in your agreement.
Plugin compatibility with your major version
Check that each plugin declares support for the exact Grafana major version you run, and that it has been tested against the minor release you plan to deploy. Major releases arrive once a year, so a plugin that worked last spring can break after an upgrade. Note the plugin version, the Grafana version and the test result in your change record before any upgrade window.
Outbound network access per plugin
Determine whether each plugin calls external hosts at runtime, such as vendor APIs, map tiles, license servers or telemetry endpoints. A plugin that needs egress can widen the exposure of a network that was designed to be closed. Review the plugin source and its configuration, then confirm the required destinations with your network team and allow only those hosts through your proxy or firewall.
Container and Kubernetes plugin handling
Confirm how your image or Helm chart installs plugins: whether they are baked into the image at build time, downloaded at container start, or mounted from a volume. Each method changes who approves a plugin, how a rollback works and whether an unsigned plugin can slip in at startup. Check the installation documentation for your packaging method and keep the plugin list in version control.
Data source plugins against your integrations
List every data source plugin in use and match each one to a supported integration you have chosen to run. A data source plugin that is installed but unused adds attack surface, and a used one that is not in your approved list is an unreviewed path to your telemetry. Compare the list with your integration inventory each quarter and after any change to a backend system.
How DeployOpen scopes and delivers plugin trust reviews
DeployOpen treats Grafana plugin trust as a documented decision, not a setting toggled to make a plugin load. We inventory the plugins your instance runs, check each one's signature level and status, and agree in writing which plugins you accept, which need a review, and which stay out. The result is a plugin policy your team can operate and an auditor can follow.
How we scope
- We inventory every installed and planned plugin, with its source, publisher and signature level.
- The written scope names the plugins under review, the Grafana versions covered and the accepted risk owner.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm whether private plugins need signing and who holds the signing keys in your environment.
How we build
- We set the plugin allow list in configuration and provisioning files so the policy is version-controlled.
- We keep allow_loading_unsigned_plugins disabled and document any exception with its owner and expiry.
- We review community plugins for maintainer activity, permissions, network calls and data access before approval.
- We test each approved plugin in a staging instance matching your production Grafana version and database.
How we hand over
- You receive a plugin register listing each approved plugin, its signature status and the reason it was accepted.
- The review checklist and exception log are delivered as documents your team can reuse for later reviews.
- We walk your operators through adding, updating and retiring plugins under the agreed policy.
- Provisioning files and configuration changes are handed over in your own repositories.
How we support
- Ongoing support, plugin upgrades and continuous review are available as a retainer.
- Retained support re-checks plugin signatures and statuses after each Grafana minor or patch release.
- We can review new plugin requests against the agreed policy and report the outcome to your team.
- Confirm response expectations and what a retainer covers in the written quote before you sign.
