Grafana dashboards are powerful and flexible tools for observing applications and infrastructure, so it’s no surprise we get a lot of questions from the community about how to embed them into their web applications.
Over the past few releases, we’ve developed a lot of options for how to do this in Grafana, but there can be confusion about how they work, and when to use each approach. That’s what this post will be about: navigating through the options, and, importantly, discussing the security implications of each one.
We’ll also provide details on one frequently asked use case that is not supported in Grafana Cloud: embedding authentication-protected dashboards in applications. We will get into why that isn’t supported in the security section.
Follow along with a ‘four golden signals’ sample dashboard
Note: Some of the features we will be discussing in this article differ between Grafana OSS and Grafana Cloud for security or configuration reasons. We will note these differences as we go.
If you want to follow along and see how the things described in this article work, we are going to use a sample dashboard on Grafana Play that is already accessible, so you can see what we’re doing and how it works.
Our sample dashboard is of the “four golden signals” (latency, errors, traffic, and saturation) used in many observability cases. This could be the type of a dashboard we reuse in other web apps. For example, we might have an internal IT portal where we want to display this dashboard. But what are our options?
Using this sample dashboard as our reference point, we’ll cover three broad topic areas in the remainder of this blog:
- Methods of embedding
- How to configure Grafana to permit iframe embedding
- Security considerations and unsupported cases
Methods of Embedding
There are four methods we’ll focus on for sharing Grafana dashboards in web apps — links, snapshots, exporting, and public dashboards. Though the steps involved will vary, all of these methods can be found in the “Sharing” button at the top of a dashboard view in Grafana.
Links are the simplest approach, and they’re just what they sound like. Grafana generates a link to the dashboard, as well as a number of options to choose from, such as the theme, whether to lock the time range, and so on.
Pros: Easy, fast, and customizable. You can link to dashboards that require authorization without passing that authorization. When the user clicks the link, they may be prompted to log in to ensure the security of your dashboard.
Cons: Links don’t count as “true embedding” because the dashboard is just like any other web link; the Grafana experience isn’t fully embedded in the application because you cannot see a dashboard, just a link to one.
Availability: Grafana OSS, Grafana Enterprise, and Grafana Cloud
Publishing a snapshot is a way of creating a moment-in-time interactive dashboard application that is publicly accessible. The result is a full mini-app that can be embedded in another site. You can generate these snapshots to be hosted by Grafana Labs, or you can host the snapshots directly on your own Grafana instance. Click here to see a snapshot I generated of our test dashboard.
Pros: Easy to build and fully interactive. Snapshots can also be deleted automatically, and they don’t create underlying hits on your data sources or excess traffic/load. If you publish snapshots to your local Grafana instance, you may have other controls (such as firewalls and network enclaves) that may somewhat limit distribution of the snapshots, rather than publishing them on the internet.
Cons: They’re public, and you still need to write iframe markup to embed a snapshot in another page.
Availability: Grafana Cloud and Grafana OSS
We’ll give this one a very brief mention, since it’s really intended for a different use case. The “Export” option, which you’ll see in the sharing menu, is for downloading a JSON version of a Grafana dashboard; this is for sharing with a different Grafana instance. As such, you can’t use it directly to embed a Grafana dashboard in a different application.
Public dashboards are a new Grafana feature currently in public preview. In order to use this feature in Grafana OSS or Grafana Enterprise, you must set the feature toggle described in the linked documentation. If you’re using Grafana Cloud, you need to contact support to request they enable this for you, or else you will not see this option in your sharing menu.
Pros: This can share a fully interactive dashboard for any time range, not just a predetermined one.
Cons: Anyone with the link has full access to the data, including the ability to adjust past time ranges in the dashboard. Reloading the dashboard will trigger extra queries against your data sources, which can cause load.
Availability: Grafana OSS and Grafana Enterprise by configuration; can be enabled in Grafana Cloud by contacting support
Note: Grafana often releases new features behind these “feature flags” that allows for users to have early access to features and provide feedback, without changing everyone’s default experience.
Grafana settings and security considerations
Typically, to embed Grafana components in a web application, you’ll use an iframe tag. When the browser requests your application, the iframe will cause it to request the Grafana resource from another site and build the total picture of the app, like so:
<p>Our portal uses Grafana!</p> <iframe src="http://grafana.o11y.party/public-dashboards/49064a01585144b88fe83a88738987b3" width="800" height="800"></iframe>
This secondary request for the iframe content is called a cross-origin request, because the browser is asking for your Grafana dashboard (Let’s say that’s hosted on
portal.o11y.party. Those requests have special security restrictions that need to be discussed.
In order to make this work, one setting is required: You must set
allow_embedding to true, or Grafana will reject embedding requests to mitigate the risk of clickjacking. Users should be aware of those risks, and why the default is false, before changing that setting.
We strongly recommend that you use the same site — here, meaning the same domain name, not same subdomain — for both the Grafana instance and the application it is embedded in. For example, if you embed a dashboard from
portal.o11y.party, these two will share the
In addition, you’ll need to be mindful of issues around the sharing of cookies between different sites. For this purpose, web security standards have developed rules around cookie passing, which you can read about here. Grafana configuration includes a
cookie_samesite option that controls what behavior Grafana will allow, and whose default value is
lax. For this post, we verified that this default can be kept as is, provided that the embedding site and the Grafana instance are same site. Please take note of the same-site recommendation above and follow it when embedding dashboards.
While it is possible to set
disabled, to have embedding work even across different sites, we do not support this in Grafana Cloud, and we do not recommend it in Grafana Enterprise or Grafana OSS since the setting is present to protect against cross-site request forgery and information leakage.
If you’re using Grafana OSS or Grafana Enterprise, just be sure to understand the risks before using this configuration. For example, it might represent an acceptable risk tradeoff when you are embedding already public data and there is no special authentication present. Provided that anonymous users are not given elevated privileges, there’s no information leakage potential if the resource is public, and public resources have no permissions to make changes to your Grafana instance. The purpose here is to establish guarantees wherever possible to prevent request forgery from damaging or changing your Grafana instance.
If you are embedding Grafana or Grafana Enterprise in a product for third parties to access, please ensure you have reviewed the open source license or your commercial agreement with Grafana Labs.
Not supported: fully embedded private dashboards with authentication
Some folks will look at the public dashboards feature and say “Yes! That’s what I want, except not public, embedded in an iframe in my application!” In our support forum, you’ll see comments like this:
“We have a web application where users are authenticated using external auth and also have IDs in Grafana, so no anonymous access. We want to embed an iframe in the app.”
This is a frequent request that we’ve heard and considered carefully. But as of this writing, it is not supported in Grafana Cloud. Here’s why.
- Embedding Grafana with authentication in another app provides a very bad user experience. Imagine seeing a pane inside of your app that displays a login prompt rather than a Grafana dashboard. The prompt then requires the user to log into the app, and then log into another app-within-the-app — again, not what you want.
- Making configuration changes necessary to support embedding opens your app to cross-site request forgery and clickjacking attacks that we do not wish to facilitate. Once a browser is enabled to make privileged calls to your Grafana instance from another application, malicious third-party libraries can do unexpected and dangerous things.
- Various work-arounds are possible to address the user experience issue (such as using an OAuth provider for Grafana and the app in question), but they don’t address the security concerns.
- Other work-arounds are possible to address the security concerns — e.g., by proxying access to Grafana through a trusted third service like NGINX — but they greatly complicate the architecture and make the entire situation more brittle and harder to maintain.
Embedding simply works better with un-privileged sources like snapshots and public dashboards. By eliminating the authentication layer and focusing on more public data, the security issues can be partially addressed (there is nothing sensitive to guard), and by eliminating the authentication layer, the “double login” user experience problem is avoided.
Final notes on security
As a note for future readers, these approaches are subject to change over time as the security landscape is dynamic and Grafana Cloud must adhere to industry-standard security technologies and procedures. Self-managed Grafana environments provide more customization options as individual organization risk tolerance can allow for more flexibility than managed platforms like Grafana Cloud. If advanced features are required for your environment, then we recommend the self-managed offerings (Grafana OSS or Grafana Enterprise). To review Grafana Cloud security and compliance details, visit our portal at trust.grafana.com.
Tradeoffs and use cases
Links, snapshots, and public dashboards are the go-to options for referring to Grafana dashboards, including in third-party applications. You can read more about each option than what we’ve covered here in Grafana’s dashboard sharing documentation.
Each of these options has tradeoffs, depending on data freshness, protection, and how dynamic and interactive the data is. Links are best when you need data protection and don’t need embedding. Snapshots are ideal when you need full interactivity but want to control data access to a particular moment in time. And public dashboards give you a much fuller range of capabilities, but without the data protection.
And remember to be mindful of these tradeoffs, since Grafana dashboards often contain sensitive information. For example, the iframe embedding option is complicated by the need for separate authentication and authorization for Grafana and the application in question — but it is possible, given careful consideration of those security considerations.
Have any further questions or issues? Feel free to drop by the Grafana community site, which is the best place to find other people’s solutions and ask questions.