Grafana / Advanced: access, dependencies, and evidence / Lesson 14

Data-source security and secret boundaries

Review network vantage, backend authorization, secret-bearing configuration, and diagnostic copies without treating a working dashboard as proof of least privilege.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Identify which component reaches the backend.
Separate viewer identity from source credentials.
Minimize secret-bearing exports and diagnostic output.

A URL is interpreted from an execution location

A backend URL must be understood from the component that actually sends the request. A hostname reachable in the browser may not be reachable from a Grafana server or plugin backend, and localhost refers to the relevant execution environment rather than automatically to the learner’s laptop. The supported path depends on plugin and configuration. Review routing, TLS trust, proxy behavior, and authentication through the approved environment, not arbitrary probing. A data-source URL can also direct server-side network access, so configuration authority and allowed destinations need deliberate ownership.

Shared source credentials define another access boundary

A user’s Grafana role and the credentials a plugin uses against a backend are not necessarily the same identity. Some integrations support reviewed identity forwarding or provider-specific mechanisms, while others use configured shared credentials. Do not assume that dashboard variables restrict those credentials to one route or tenant. Enforce the required data boundary through supported backend and Grafana access controls, with edition and plugin capabilities stated explicitly. A successful connection or panel demonstrates only the path exercised; it does not prove that broader queries are prevented or that a background evaluator has equivalent access.

Secret fields are not ordinary dashboard content

Data-source configuration can contain plugin-specific ordinary settings and secret-bearing settings. The illustrative JSON uses a synthetic custom-header value in secureJsonData, with the corresponding header name in jsonData, under a compatible integration assumption. It is not a real token or a complete provisioning request. Readback may indicate that a secret is configured without returning its value, but exact storage, encryption, rotation, and plugin behavior require version-specific documentation. A field being called secure does not remove the need to review transport, logging, access, and backup handling.

json Illustrative source-header configuration fragment

{"jsonData":{"httpHeaderName1":"X-Lab-Context"},"secureJsonData":{"httpHeaderValue1":"synthetic-lab-only"}}

The value is synthetic and the fragment assumes compatible plugin fields. It is unexecuted and proves no secret storage, encryption, or backend authentication.

Minimize diagnostic configuration before sharing

The local JSON example retains only a synthetic name, UID, and type for a review record. It deliberately omits the URL and secure configuration rather than assuming only one known password key is sensitive. This is not a complete redactor for Grafana, plugins, or arbitrary nested data. Query text, headers, URLs, error messages, and response rows can expose secrets or personal context outside the expected field. Keep diagnostic access and retention controlled, and use a necessary-field policy. A successful allowlist fixture does not prove every export path follows that policy.

python Offline diagnostic-config allowlist

import json
record = json.loads('{"name":"Transit Lab","uid":"transit-lab-prom","type":"prometheus","url":"https://metrics.invalid","secureJsonData":{"httpHeaderValue1":"synthetic-lab-only"}}')
allowed = {"name", "uid", "type"}
review_record = {key:value for key,value in record.items() if key in allowed}
assert "secureJsonData" not in review_record and "url" not in review_record
print(sorted(review_record))

Expected output

['name', 'type', 'uid']

Only fixed synthetic JSON is processed. The check validates three retained keys and does not inspect, redact, export, or secure any real configuration.

Verify boundaries through the authorized owner

A real review should cover allowed and denied source queries, execution identity, destination trust, credential lifecycle, diagnostic leaks, and supported edition-specific permissions. Do not test access by guessing endpoints, discovering secrets, or broadening privileges from an educational example. This lesson parses synthetic JSON only and performs no network, account, security scan, authentication, source configuration, or secret operation. It creates no credential and validates no encryption or isolation property. Preserve the distinction between intended design and tested evidence so a working panel cannot be mistaken for a verified security boundary.

Common errors and fixes

localhost is assumed to mean the browser machine

Why it happens: Execution vantage was not identified.
How to fix it: Review the actual plugin request path.
Prevent it next time: Document network ownership and destination scope.

A hidden route variable is called backend isolation

Why it happens: Shared credentials can query broader data.
How to fix it: Enforce the actual trusted source and backend authorization.
Prevent it next time: Test denied queries in an authorized isolated plan.

A diagnostic export includes secure configuration

Why it happens: Configuration was treated as ordinary shareable content.
How to fix it: Minimize necessary fields before approved sharing.
Prevent it next time: Review nested fields, URLs, errors, and response data.

Check your understanding

1. Can a secureJsonData example establish that a real installation encrypts and rotates secrets correctly?

Show worked solution

No. It shows a configuration concept under a plugin assumption. Actual storage, key management, access, transport, backup, and rotation behavior require the selected version and authorized verification. The synthetic JSON is not evidence of an operational secret lifecycle.

2. Why should a read-only dashboard user’s backend data scope be reviewed separately from folder access?