Grafana’s plugin system is designed with security in mind, and by default, it only allows plugins signed by Grafana Labs. This prevents malicious code from being injected into your dashboards. However, you might have internal plugins or plugins from trusted third parties that aren’t signed. Enabling these requires a specific configuration change.
Let’s see this in action with a hypothetical internal plugin called my-custom-datasource.
First, we need to locate Grafana’s configuration file. On most Linux systems, this is /etc/grafana/grafana.ini.
# Example: Check if grafana.ini exists
ls -l /etc/grafana/grafana.ini
Now, we need to edit this file to allow unsigned plugins. We’ll be modifying the [plugins] section.
[plugins]
# Set to true to enable loading unsigned plugins.
# Default is false.
enable_unsigned_plugins = true
After making this change, we need to restart the Grafana server for the configuration to take effect.
# Example: Restarting Grafana service on systemd-based systems
sudo systemctl restart grafana-server
Once Grafana restarts, you can navigate to the "Plugins" section in the Grafana UI. You should now be able to search for and install your my-custom-datasource plugin, even though it’s not signed.
The core problem Grafana’s signing mechanism solves is ensuring the integrity and origin of the code running within your Grafana instance. When you allow unsigned plugins, you’re essentially telling Grafana, "I trust the source of this plugin and I’m willing to take responsibility for its security."
Internally, Grafana checks the signature of a plugin against a known set of trusted certificates. If enable_unsigned_plugins is false (the default), and a plugin lacks a valid signature, Grafana will refuse to load it, often resulting in a "plugin signed by an unknown author" error in the Grafana server logs.
The enable_unsigned_plugins = true setting bypasses this signature verification step entirely. Grafana will then proceed to load the plugin as long as its directory structure is correct and it doesn’t violate other fundamental plugin loading rules.
When you’re developing your own plugins, you’ll often want to test them locally before going through the process of signing them. Setting enable_unsigned_plugins = true is crucial for this development workflow. You can build your plugin, place it in the Grafana plugins directory (e.g., /var/lib/grafana/plugins/), and Grafana will pick it up after a restart.
Beyond development, this setting is also useful for organizations that have strict internal policies about plugin development and auditing. If you have a robust internal process for vetting and approving plugins, you might decide that relying on Grafana’s signing infrastructure isn’t necessary. However, this comes with the significant caveat that your organization is solely responsible for the security of those plugins.
The most surprising aspect of this setting is how little it actually changes in terms of the plugin’s code. The plugin itself still needs to adhere to Grafana’s plugin API and development best practices. The enable_unsigned_plugins flag is purely a Grafana server configuration that dictates whether the signature check happens. A poorly written or malicious unsigned plugin will still be malicious or poorly written; Grafana just won’t stop you from running it.
The next challenge you’ll likely face is managing different versions of these unsigned plugins across multiple Grafana instances or ensuring they are properly deployed and updated within your infrastructure.