Grafana Public Dashboards Secure Sharing Prompt

You are a senior Grafana admin who exposes public dashboards to external stakeholders without leaking sensitive data.

I will provide:
- The dashboard to share and the audience
- The data sources it queries
- Compliance or exposure constraints

Your job:

1. **Confirm the public dashboard model**:
   - Public dashboards render read-only, no login, via a shareable URL
   - They only run the queries saved in the dashboard, on the server side
   - Template variables and annotations may be limited
2. **Enable the feature safely**:
   - Turn on public dashboards in config (`[public_dashboards] enabled`)
   - Grant only specific admins the rights to create them
3. **Scope the data**:
   - Review every panel's query — public means anyone with the link sees it
   - Remove panels with PII, cost, or internal hostnames
   - Prefer a purpose-built dashboard over exposing an internal one
4. **Control time range and refresh**:
   - Lock the time range; disable open-ended refresh to limit load
   - Enable query result caching to protect the data source
5. **Manage the lifecycle**:
   - Track the public URL and pause/revoke when no longer needed
   - Rotate by deleting and recreating (URL changes)
6. **Harden the edges**:
   - Put it behind your CDN/WAF; consider IP allowlists at the proxy
   - Set a share expiry where supported
7. **Audit**:
   - List all public dashboards periodically via the API
   - Confirm none expose data sources they shouldn't

Mark DESTRUCTIVE: enabling public dashboards org-wide, exposing a dashboard with sensitive queries, deleting a public config (breaks the shared URL).

---

Dashboard and audience: [DESCRIBE]
Data sources: [DESCRIBE]
Constraints: [DESCRIBE]

Why this prompt works

Public dashboards are the easiest way to leak data in Grafana because “share” feels harmless. This prompt forces a panel-by-panel data review, locks the time range, enables caching to protect the data source, and adds a lifecycle/audit step — the parts teams skip until a hostname or cost figure ends up on the open internet.

How to use it

1. Build a purpose-made dashboard, don’t expose an internal one.
2. Review every query for sensitive output.
3. Lock time range, enable caching.
4. Audit and revoke on a schedule.

Useful commands

# List public dashboards via the API
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://grafana:3000/api/dashboards/public-dashboards | jq '.publicDashboards[] | {uid, dashboardUid, isEnabled}'

# Create a public dashboard for a given dashboard UID
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  http://grafana:3000/api/dashboards/uid/$DASH_UID/public-dashboards \
  -d '{"isEnabled": true, "timeSelectionEnabled": false, "annotationsEnabled": false}'

# Revoke (delete) a public dashboard
curl -s -X DELETE -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://grafana:3000/api/dashboards/uid/$DASH_UID/public-dashboards/$PUBLIC_UID

# grafana.ini
[public_dashboards]
enabled = true

Example config

{
  "isEnabled": true,
  "timeSelectionEnabled": false,
  "annotationsEnabled": false,
  "share": "public"
}

Common findings this catches

• Leaked internal data → sensitive panel left on the shared dashboard.
• Data source overload → open refresh with no caching.
• Orphaned URLs → public dashboards never revoked.
• Feature off → [public_dashboards] enabled not set.
• Variable exposure → template vars reveal all label values.
• No audit trail → nobody lists public dashboards periodically.

When to escalate

• Compliance/legal review of what may be shared publicly.
• WAF/IP allowlist changes at the edge — network team.
• Recurring external reporting needs — consider Enterprise reporting instead.