Embed Grafana Dashboards in Splunk: The Complete 2026 Integration Guide

You can embed Grafana in Splunk today using four proven patterns — iframe embedding, reverse-proxy header injection, API rendering with KV Store, and a full SAML/OAuth SSO bridge. Each works in production environments running Grafana 12.x and Splunk 9.x. What this covers: pattern selection, step-by-step configuration for all four methods, CORS solutions, failure-mode mitigations, and a decision framework that tells you which pattern fits your security posture.

Last Updated: June 2026

---

Splunk and Grafana serve overlapping but distinct purposes. Splunk excels at log search, correlation, and machine-data analytics. Grafana excels at time-series visualization, multi-source dashboards, and plugin-rich panels. Teams running both tools constantly ask the same question: can operators see Grafana visuals without leaving the Splunk UI?

The answer is yes — but the implementation complexity varies widely depending on your authentication architecture. This guide walks through all four integration patterns, explains when each is appropriate, and flags the failure modes teams hit most often.

Figure 1: The four Grafana-in-Splunk integration patterns, mapped by auth complexity and operational overhead.

---

Pattern Selection Matrix

Use this table to choose your pattern before reading the deep dives. Mismatching pattern to security posture is the single most common cause of failed integrations.

Pattern	Auth model	Grafana version	Splunk version	Complexity	Best for
Iframe + anonymous auth	No auth on Grafana	12.x (anonymous org enabled)	9.x	Low	Internal read-only dashboards, air-gapped labs
Reverse proxy + header injection	Proxy-authenticated user	12.x (auth.proxy enabled)	9.x	Medium	Orgs with a central nginx/Envoy tier already in place
API rendering + KV store	Service account token	12.x (Grafana Image Renderer)	9.x (KV Store enabled)	Medium-High	Regulated environments where live iframes violate CSP
SAML/OAuth SSO bridge	IdP-delegated SSO	12.x (SAML/OAuth2 enabled)	9.x (SAML enabled)	High	Enterprise with Okta, Azure AD, or Ping Identity

Rule of thumb: start with the lowest-complexity pattern your security team will approve. Iframe embedding is fast to ship and easy to debug. SAML/OAuth is the right long-term choice for multi-tenant or regulated environments.

---

Terminology Primer

Before diving into configuration, align on these terms. They appear throughout every pattern.

Grafana anonymous access — an org-level flag in grafana.ini that allows unauthenticated GET requests to dashboards. Grafana 12.x scopes this per-organization, so you can enable it on a read-only “embed” org without exposing your primary org.

Proxy authentication (auth.proxy) — Grafana reads a trusted HTTP header (e.g., X-WEBAUTH-USER) and treats the value as the authenticated username. The proxy (nginx, Envoy, Traefik) must strip this header on inbound public requests and inject it only after verifying the caller’s identity.

Grafana Image Renderer — a headless-Chromium plugin that renders a Grafana panel or dashboard to a PNG or PDF. Available as a Docker sidecar (grafana/grafana-image-renderer) or a bundled plugin. Required for Pattern 3.

Splunk KV Store — a MongoDB-backed key-value lookup store built into Splunk Enterprise and Splunk Cloud 9.x. Pattern 3 uses it to cache rendered image URLs so the Splunk dashboard can display them without live iframe traffic.

CORS (Cross-Origin Resource Sharing) — browsers enforce a same-origin policy. Because Splunk and Grafana run on different hostnames, the browser blocks cross-origin iframe loads unless Grafana returns the correct Content-Security-Policy and X-Frame-Options headers. This is covered in detail in its own section.

Grafana Service Account — introduced in Grafana 8.x, stabilized in Grafana 10.x, and the recommended token holder in Grafana 12.x. Service accounts replace the older API key model and support fine-grained RBAC.

---

Pattern 1 — Iframe Embedding with Anonymous Auth

This is the fastest pattern to implement. It works best for internal tooling where the Grafana instance sits on a trusted network segment and no user-level accountability is required for dashboard views.

Grafana 12.x configuration

Edit grafana.ini (or the equivalent environment variables for Grafana deployed via Helm/Operator):

[security]
allow_embedding = true
cookie_samesite = disabled

[auth.anonymous]
enabled = true
org_name = EmbedOrg
org_role = Viewer

[server]
root_url = https://grafana.internal.example.com

Key points for Grafana 12.x:
– allow_embedding = true removes the X-Frame-Options: SAMEORIGIN header that blocks iframes.
– cookie_samesite = disabled is required when the iframe parent (Splunk) is on a different subdomain. Without it, the browser drops the Grafana session cookie and anonymous org auth silently fails.
– Create a dedicated org named EmbedOrg in Grafana and move only the dashboards you want to expose to that org. This limits blast radius if the anonymous endpoint is ever reached from outside the trusted network.

Splunk dashboard XML

In Splunk Enterprise 9.x Simple XML dashboards, embed the Grafana panel using an <html> panel element:

<dashboard>
  <label>Operations Overview</label>
  <row>
    <panel>
      <title>Grafana — Request Latency P99</title>
      <html>
        <![CDATA[
          <iframe
            src="https://grafana.internal.example.com/d/abc123/request-latency?orgId=2&kiosk=tv&from=now-1h&to=now&theme=dark"
            width="100%"
            height="500"
            frameborder="0"
          ></iframe>
        ]]>
      </html>
    </panel>
  </row>
</dashboard>

For Splunk Dashboard Studio (the newer React-based editor in Splunk 9.x), use an Absolute or Grid layout block with a text/html visualization and the same iframe markup.

URL parameters to know

Parameter	Effect
kiosk=tv	Hides the Grafana nav bar and top menu — recommended for embeds
theme=dark or theme=light	Forces the panel theme regardless of viewer preference
from / to	Sets the time range; accepts relative (now-1h) or epoch ms
var-hostname=web01	Injects a dashboard variable — useful for filtering by Splunk search results

Security hardening

Even on an internal network, restrict anonymous access further:

1. Place Grafana behind an internal load balancer with IP allowlist rules. Allow only the CIDR blocks that contain Splunk servers and operator workstations.
2. Enable Grafana’s built-in rate limiter in grafana.ini under [rate_limiting] to prevent scraping.
3. Audit EmbedOrg dashboard permissions quarterly. Anonymous viewers in Grafana 12.x can be restricted from datasource query access via the data source RBAC panel.

---

Pattern 2 — Reverse Proxy with Header Injection

This pattern lets Splunk and Grafana share a user identity without a full SSO deployment. A reverse proxy (typically nginx or Envoy) sits in front of Grafana, authenticates the inbound request using a session cookie or JWT it can validate, and then injects the trusted X-WEBAUTH-USER header before forwarding to Grafana.

Figure 2: Request flow for Pattern 2. nginx validates the caller, strips any client-supplied auth header, and injects the trusted username header before forwarding to Grafana.

Grafana 12.x configuration

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true
sync_ttl = 60
whitelist = 10.0.1.0/24
enable_login_token = false

whitelist restricts proxy auth to requests originating from the nginx/Envoy subnet. This prevents an attacker from forging the header by hitting Grafana directly.

nginx configuration

upstream grafana_backend {
    server grafana.internal.example.com:3000;
    keepalive 16;
}

server {
    listen 443 ssl http2;
    server_name grafana-proxy.internal.example.com;

    ssl_certificate     /etc/ssl/grafana-proxy.crt;
    ssl_certificate_key /etc/ssl/grafana-proxy.key;

    location / {
        # Strip any client-supplied auth header — critical security step
        proxy_set_header X-WEBAUTH-USER "";

        # Validate the caller's session and resolve their username
        # (integrate with your auth_request endpoint or use ngx_http_auth_request_module)
        auth_request /auth-validate;
        auth_request_set $grafana_user $upstream_http_x_auth_user;

        # Inject the resolved username
        proxy_set_header X-WEBAUTH-USER $grafana_user;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://grafana_backend;

        # Required for iframe embedding from Splunk
        proxy_hide_header X-Frame-Options;
        add_header Content-Security-Policy "frame-ancestors 'self' https://splunk.example.com";
    }

    location /auth-validate {
        internal;
        proxy_pass https://auth.example.com/validate;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
}

Auto-provisioned Grafana accounts

With auto_sign_up = true, Grafana 12.x creates a Viewer-role account the first time it sees a new username from the proxy. This is usually acceptable for read-only Splunk embeds. If you need role mapping, use [auth.proxy]‘s headers key to pass a role header alongside the username header, and configure Grafana’s role sync accordingly.

Envoy alternative

If your stack already runs Envoy (e.g., as part of a service mesh), the equivalent is an ext_authz filter that validates the caller and populates a response header. The Envoy config is more verbose but the trust model is identical: validate before injecting, never trust client-supplied headers. For teams already running a sidecarless eBPF service mesh like Cilium, the mTLS layer between the proxy and Grafana can be enforced at the network policy level rather than in application config, which simplifies the whitelist requirement.

---

Pattern 3 — API Rendering with Splunk KV Store

This pattern avoids iframes entirely. A backend process calls Grafana’s rendering API, stores the resulting PNG in Splunk’s KV Store, and the Splunk dashboard displays the stored image. It is the right choice when your Content Security Policy prohibits iframes or when you need to archive dashboard snapshots for compliance.

Figure 3: Sequence for Pattern 3. The renderer calls Grafana’s /render/ API, stores the PNG reference in KV Store, and the Splunk dashboard fetches it on load.

Prerequisites

• Grafana Image Renderer deployed as a Docker sidecar or a bundled plugin (grafana-image-renderer).
• A Grafana 12.x service account with Viewer role on the target dashboards.
• Splunk KV Store enabled (default in Splunk Enterprise 9.x and Splunk Cloud 9.x).
• A Splunk custom command or scripted input to run the render job.

Grafana Image Renderer setup

[rendering]
server_url = http://grafana-renderer:8081/render
callback_url = http://grafana:3000/

Render a panel to PNG via the API:

GET https://grafana.example.com/render/d-solo/abc123/request-latency
    ?orgId=1
    &panelId=5
    &from=now-1h
    &to=now
    &width=1200
    &height=400
    &tz=UTC
Authorization: Bearer <service-account-token>

The response is a raw PNG binary. Store it to a reachable object store (S3, GCS, MinIO) or serve it from a static file server.

Splunk KV Store schema

Define the collection in collections.conf (in your Splunk app):

[grafana_renders]
field.panel_id = string
field.dashboard_slug = string
field.image_url = string
field.rendered_at = time
field.time_range = string

And the lookup in transforms.conf:

[grafana_renders_lookup]
external_type = kvstore
collection = grafana_renders
fields_list = panel_id, dashboard_slug, image_url, rendered_at, time_range

Splunk search to display the image

| inputlookup grafana_renders_lookup
| where panel_id="latency-p99"
| sort -rendered_at
| head 1
| eval img_html="<img src='" . image_url . "' style='max-width:100%;border:none;'/>"
| table img_html

Use a Splunk <html> panel with the search result to render the image inline.

Automation: render-and-store job

A simple Python script (run as a Splunk scripted input or a Kubernetes CronJob) handles the loop:

import requests, time, os

GRAFANA_URL = os.environ["GRAFANA_URL"]
TOKEN       = os.environ["GRAFANA_SA_TOKEN"]
SPLUNK_URL  = os.environ["SPLUNK_URL"]
SPLUNK_TOKEN = os.environ["SPLUNK_HEC_TOKEN"]
OBJECT_STORE = os.environ["OBJECT_STORE_URL"]

panels = [
    {"dashboard": "abc123", "panel_id": 5, "slug": "latency-p99"},
    {"dashboard": "def456", "panel_id": 3, "slug": "error-rate"},
]

for panel in panels:
    resp = requests.get(
        f"{GRAFANA_URL}/render/d-solo/{panel['dashboard']}/x",
        params={"panelId": panel["panel_id"], "from": "now-1h", "to": "now",
                "width": 1200, "height": 400, "tz": "UTC"},
        headers={"Authorization": f"Bearer {TOKEN}"},
        timeout=30,
    )
    resp.raise_for_status()
    # Upload to object store, get public URL
    img_url = upload_to_store(resp.content, panel["slug"], OBJECT_STORE)
    # Write to Splunk KV Store via REST
    requests.post(
        f"{SPLUNK_URL}/servicesNS/nobody/myapp/storage/collections/data/grafana_renders",
        headers={"Authorization": f"Splunk {SPLUNK_TOKEN}"},
        json={"panel_id": panel["slug"], "image_url": img_url,
              "rendered_at": int(time.time()), "time_range": "1h"},
    )

---

Pattern 4 — SAML/OAuth SSO Bridge

This is the enterprise-grade pattern. Both Splunk 9.x and Grafana 12.x can be configured as SAML or OAuth2 service providers against a shared Identity Provider. When a user authenticated to Splunk navigates to an embedded Grafana iframe, the browser presents the IdP session cookie and Grafana grants access without a second login prompt.

Figure 4: SSO bridge flow. Both Splunk and Grafana are registered as SAML SPs with the same IdP. The browser session established at Splunk login is reused silently for Grafana iframe loads.

Grafana 12.x SAML configuration

[auth.saml]
enabled = true
certificate_path = /etc/grafana/saml-cert.pem
private_key_path  = /etc/grafana/saml-key.pem
idp_metadata_url  = https://idp.example.com/metadata
max_issue_delay   = 90s
metadata_valid_duration = 48h
assertion_attribute_name  = displayName
assertion_attribute_login = mail
assertion_attribute_email = mail
assertion_attribute_groups = groups
role_values_viewer = grafana-viewer
role_values_editor = grafana-editor
role_values_admin  = grafana-admin
allow_sign_up = true

Register Grafana’s metadata at https://grafana.example.com/saml/metadata with your IdP. Add the Splunk assertion consumer service URL as a second SP in the same IdP application if they are not already separate registrations.

OAuth2 alternative (Okta/Azure AD)

[auth.generic_oauth]
enabled = true
name = Okta
client_id = <okta-client-id>
client_secret = <okta-client-secret>
auth_url = https://example.okta.com/oauth2/v1/authorize
token_url = https://example.okta.com/oauth2/v1/token
api_url   = https://example.okta.com/oauth2/v1/userinfo
scopes = openid profile email groups
role_attribute_path = contains(groups[*], 'grafana-admin') && 'Admin' || contains(groups[*], 'grafana-editor') && 'Editor' || 'Viewer'
allow_sign_up = true

iframe embedding with SSO

Once both Splunk and Grafana authenticate against the same IdP, the iframe embedding from Pattern 1 works with authenticated users instead of anonymous access. Re-add allow_embedding = true in grafana.ini and set cookie_samesite = none with cookie_secure = true:

[security]
allow_embedding = true
cookie_samesite = none
cookie_secure = true

SameSite=None; Secure is required for third-party cookies in modern browsers (Chrome 80+, Firefox 79+, Safari 14+). Without this, the browser silently drops the Grafana session cookie in the cross-origin iframe and the user sees the Grafana login screen instead of the dashboard.

Group-to-role mapping

Map your IdP groups to Grafana roles at the org level. In Grafana 12.x, group sync runs on every login and on a configurable background interval (sync_ttl). Keep the mapping simple: read-only Splunk operators should land in the Viewer role so they cannot modify Grafana dashboards from within the embedded iframe.

---

The CORS Problem and Solutions

CORS errors are the most common reason embedding attempts fail silently. The browser enforces the same-origin policy: because splunk.example.com and grafana.example.com are different origins, the browser refuses to render the iframe content unless Grafana explicitly permits the embedding origin.

What browsers block

• X-Frame-Options: SAMEORIGIN — set by Grafana by default. Blocks any cross-origin iframe. Resolved by allow_embedding = true.
• Content-Security-Policy: frame-ancestors 'self' — the CSP equivalent, used in Grafana 12.x when the legacy X-Frame-Options header is removed. Override by setting content_security_policy_template in grafana.ini.
• Preflight blocked — POST/PUT requests from JavaScript in the Splunk page to Grafana’s API fail if Grafana doesn’t return Access-Control-Allow-Origin.

Grafana 12.x CSP override

[security]
content_security_policy = true
content_security_policy_template = "script-src 'self' 'nonce-$__nonce' 'unsafe-eval'; object-src 'none'; font-src 'self'; style-src 'self' 'nonce-$__nonce' 'unsafe-inline'; img-src * data:; base-uri 'self'; form-action 'self'; frame-ancestors 'self' https://splunk.example.com;"

The key addition is frame-ancestors 'self' https://splunk.example.com. Replace the URL with your Splunk hostname. For multiple Splunk instances, space-separate them: frame-ancestors 'self' https://splunk-a.example.com https://splunk-b.example.com.

nginx proxy_hide_header pattern

If you cannot change Grafana’s grafana.ini (e.g., a hosted Grafana Cloud instance), add the CSP and remove the blocking header at the nginx layer:

proxy_hide_header X-Frame-Options;
proxy_hide_header Content-Security-Policy;
add_header Content-Security-Policy "frame-ancestors 'self' https://splunk.example.com;";

Note: stripping CSP headers at the proxy reduces your defense-in-depth posture. Only do this on internal-facing proxies, never on internet-facing ones.

Browser compatibility notes

Safari 14+ dropped support for X-Frame-Options: ALLOW-FROM, which was the old header-based way to whitelist a specific origin for iframes. If your operators use Safari, you must use the CSP frame-ancestors directive. X-Frame-Options on its own is insufficient. See the MDN documentation on X-Frame-Options for the full compatibility matrix.

---

Failure Modes and Mitigations

These are the failure modes teams hit most often, ranked by frequency.

Blank iframe / white panel

Symptom: the iframe panel in Splunk renders as a white rectangle with no error visible in the Splunk UI.
Cause: almost always a CORS or CSP header mismatch. The browser blocked the iframe load silently.
Diagnosis: open browser devtools (F12) → Console. Look for Refused to display errors referencing X-Frame-Options or Content-Security-Policy.
Fix: apply the CSP override from the CORS section above.

Login redirect loop

Symptom: the iframe shows the Grafana login page; the user logs in; Grafana redirects back to the login page.
Cause: cookie_samesite is not set to none or disabled. The browser is dropping the post-login session cookie because it is a third-party cookie inside an iframe.
Fix: set cookie_samesite = none and cookie_secure = true in grafana.ini. Ensure Grafana is served over HTTPS (required for SameSite=None; Secure).

Proxy auth fails for some users

Symptom: some operators see the Grafana login screen inside Splunk; others see the dashboard.
Cause: the nginx auth_request endpoint is returning a username that does not match any Grafana user, and auto_sign_up is set to false.
Fix: enable auto_sign_up = true or pre-provision user accounts in Grafana. Check that the header value from the auth endpoint is a valid Grafana username (case-sensitive).

Image renderer timeout

Symptom: Pattern 3 render jobs complete for small dashboards but time out for dashboards with more than 10 panels.
Cause: the Image Renderer’s headless Chromium instance runs all panels sequentially before returning. Large dashboards exceed the default 30-second timeout.
Fix: increase rendering_viewport_max_width and rendering_viewport_max_height in Grafana’s renderer config. Render panels individually (by panelId) instead of full dashboards. Run multiple renderer instances behind a load balancer for high-throughput environments.

SAML assertion mismatch

Symptom: Grafana rejects SAML assertions with Failed to look up user based on login.
Cause: the IdP is sending a different attribute for login than what assertion_attribute_login is configured to read.
Fix: capture the raw SAML assertion (use the browser’s SAML tracer extension or the IdP’s debug log) and verify the attribute names. Common mismatch: IdP sends email but Grafana config specifies mail.

KV Store lookup returns stale images

Symptom: the Splunk dashboard shows outdated Grafana panels that do not reflect recent data.
Cause: the render job is not running on schedule, or it is completing but the KV Store lookup is cached by Splunk’s search scheduler.
Fix: add a rendered_at timestamp to every KV Store record and filter to records younger than your SLA. Set | search rendered_at > relative_time(now(), "-15m") in the Splunk search driving the image panel.

---

When to Abandon Embedding and Migrate

Embedding has real limits. Consider migrating to a unified observability platform or changing your data architecture when:

Your embedding config requires more than one full-time engineer to maintain. The nginx proxy config, Grafana role sync, KV Store jobs, and SAML attribute mappings compound. If a single engineer leaving your team would break the integration, the complexity cost exceeds the value.

You need bidirectional data flow. Embedding is read-only. If operators need to annotate Grafana events from Splunk, or if you want Splunk alert actions to modify Grafana dashboard states, embedding is the wrong pattern. Consider the Grafana Splunk data source plugin instead, which pulls Splunk SPL results into native Grafana panels — inverting the integration direction entirely.

Your security team requires row-level data access control. Embedded iframes inherit the Grafana user’s access level. If you need Splunk RBAC roles to limit which time ranges or data subsets a user sees inside the Grafana panel, iframe embedding cannot enforce that boundary. API rendering (Pattern 3) can enforce it at query time, but adds significant operational complexity. At that point, a unified platform that natively supports RBAC is usually the cleaner solution.

You are running more than three Grafana orgs for the sole purpose of segmenting embedded dashboards. This is a maintenance anti-pattern. Each org multiplies the surface area for sync issues between your IdP groups and Grafana roles. Flatten the org structure and use folder-level RBAC in Grafana 12.x instead.

Your Splunk deployment is moving to Splunk Observability Cloud. The Splunk Observability suite includes its own charting engine. Evaluate whether you actually need Grafana panels in that context, or whether the Splunk Observability dashboards meet your requirements natively.

---

Decision Framework

Answer these four questions in order to select your pattern:

1. Does your security policy allow unauthenticated read access to monitoring dashboards on the internal network?
– Yes → Pattern 1 (iframe + anonymous auth). Fastest to ship.
– No → continue to question 2.

2. Do you already have an nginx or Envoy reverse proxy in front of Grafana (or can you add one)?
– Yes → Pattern 2 (reverse proxy + header injection). Good balance of security and simplicity.
– No → continue to question 3.

3. Is your Content Security Policy incompatible with iframes, or do you need static image snapshots for compliance archiving?
– Yes → Pattern 3 (API rendering + KV Store). No iframes; snapshots are auditable.
– No → continue to question 4.

4. Do both Splunk and Grafana authenticate against a shared IdP (Okta, Azure AD, Ping)?
– Yes → Pattern 4 (SAML/OAuth SSO bridge). Cleanest user experience; no second login.
– No → revisit Pattern 2 with a lightweight auth proxy, or deploy an IdP.

If none of the four patterns fit, the right answer is usually to invert the integration: bring Splunk data into Grafana via the Splunk data source plugin rather than embedding Grafana into Splunk.

---

FAQ

Can I embed Grafana in Splunk Cloud (not just Splunk Enterprise)?
Yes. Splunk Cloud 9.x supports the same Simple XML <html> panel syntax and Dashboard Studio custom visualizations that Splunk Enterprise does. The main constraint is that Splunk Cloud’s CSP for dashboard HTML panels may be stricter than on-premises deployments. Test in a development workspace and check the browser console for CSP errors before deploying to production. Pattern 3 (API rendering) avoids this issue entirely because it does not use iframes.

Does Grafana 12.x still support API keys, or do I have to use service accounts?
Grafana 12.x still accepts legacy API keys for backwards compatibility, but they are deprecated. Service accounts are the recommended approach for all new integrations. Service accounts support fine-grained RBAC, token rotation without downtime, and audit logging — none of which legacy API keys provide. Migrate legacy keys to service accounts before they are removed in a future Grafana release. See the Grafana service accounts documentation for migration steps.

What is the performance impact of Pattern 3 on my Grafana instance?
The Image Renderer runs headless Chromium, which is memory-intensive. Each render job consumes roughly 200–400 MB of RAM and one CPU core for the duration of the render (typically 5–20 seconds for a standard dashboard). For production deployments, run the renderer as a separate Docker container or Kubernetes Deployment rather than as a Grafana plugin process. This isolates the memory footprint and lets you scale renderer replicas independently of the Grafana application tier. See Grafana Image Renderer documentation for resource recommendations.

My Grafana panels use live WebSocket streams. Will they work in an embedded iframe?
WebSocket connections from within a cross-origin iframe work in most modern browsers, subject to the same CORS and CSP rules as HTTP requests. The main practical issue is that WebSocket connections from inside the iframe are subject to the same cookie restrictions as HTTP requests: if SameSite=None; Secure is not set on the Grafana session cookie, the WebSocket handshake will fail because the browser refuses to send the authentication cookie cross-origin. Apply the cookie settings from Pattern 4 and test with the browser’s Network tab open, filtering by WS connections.

How do I pass the currently-selected Splunk time range into the embedded Grafana panel?
Splunk Dashboard Studio exposes JavaScript APIs that you can use to read the current time picker selection. Write a custom visualization or use a <html> panel with inline JavaScript that constructs the Grafana iframe src URL dynamically, substituting from and to epoch-millisecond values from the Splunk time picker. This requires Splunk 9.x Dashboard Studio and is not available in the legacy Simple XML editor. The Splunk documentation covers the Dashboard Studio JavaScript API for building custom visualizations that can read shared inputs.

Can I use Grafana Scenes (the new Grafana 12.x dashboard architecture) with Pattern 1 or 2?
Yes. Grafana Scenes-based dashboards (introduced as opt-in in Grafana 10.x and stabilized in Grafana 11–12.x) produce the same URL structure and behave identically from the browser’s perspective for embedding purposes. The kiosk=tv parameter, time range parameters, and template variable injection all work the same way. Scenes does not change the HTTP header behavior or the CORS surface area.

---

Further Reading

• Grafana authentication documentation (Grafana 12.x) — authoritative reference for all auth.proxy, SAML, and OAuth2 configuration options.
• Splunk REST API Reference — KV Store — covers the collections and data endpoints used in Pattern 3.
• MDN Web Docs — Content-Security-Policy: frame-ancestors — browser compatibility table and syntax reference for the directive that controls iframe embedding.
• Cilium service mesh and sidecarless eBPF deep dive (2026) — if you are already running Cilium as your service mesh, its network policies can enforce the proxy-to-Grafana trust boundary described in Pattern 2 without additional application-layer config.
• Grafana Image Renderer documentation — resource requirements, Docker sidecar setup, and troubleshooting for Pattern 3.

---

Riju is a technical architect and writer focused on observability, IoT data platforms, and digital twin infrastructure. He writes at iotdigitaltwinplm.com.