You are connecting Grafana to a metrics and logs backend shared by several teams. What authentication options does a Grafana data source offer, how are its secrets stored, and what is the fundamental authorization gap you have to design around?

## The authentication surface A Grafana data source's configuration form is, for HTTP-based backends, a fairly uniform set of options: - **No auth** — appropriate only inside a trusted network boundary, and even then it means anything that can reach the backend can read everything. - **Basic auth** — username and password, injected server-side. - **Bearer token / Authorization header** — via the custom HTTP headers mechanism, which lets you add arbitrary header name/value pairs where the value is stored as a secret. - **Custom headers as tenant selectors** — the same mechanism carries a tenancy header (for example the org/tenant header used by multi-tenant metric and log backends), which is how one backend serves many isolated tenants. - **TLS options** — a CA certificate to trust a private authority, a client certificate and key for mutual TLS, a server-name override, and a "skip verify" switch that should be treated as a defect in production. - **Cloud-provider auth** — request signing with access keys or an assumed role, or managed workload identity, depending on the provider plugin. - **Forwarded user identity** — an option to attach the signed-in user's OAuth access token (or an identity assertion) to the outgoing request, so the backend sees *the user*, not Grafana. - **Timeouts, connection limits and proxy settings** — unglamorous but load-bearing, since a data source with no timeout turns a slow backend into a hung Grafana. ## How secrets are stored Grafana splits a data-source configuration into two buckets. Non-sensitive settings live as plain JSON in Grafana's database and are returned by the configuration API — anyone with configuration read access sees them. Sensitive fields live in a separate encrypted bucket, encrypted with the instance's secret key; deployments can wrap that key with an external key-management service so the database alone is not enough to decrypt. The important behavioural detail is that secure fields are **write-only through the API and UI**: once saved, the value is never returned, and the form shows a "configured" state with a reset control. This is why you cannot recover a lost password from Grafana, why an export of a data source is not a credential leak, and why automated configuration must supply the secret from its own source of truth every time rather than reading it back. Rotating the instance secret key requires re-encrypting stored secrets, which is a planned operation, not an emergency one — worth knowing before an incident forces it. ## The authorization gap This is the part that separates a senior answer. Grafana's query API takes a **data-source UID** and a query. It does not take a dashboard. So the ability to see a dashboard and the ability to query its data are different things: - A user who can reach a data source can craft arbitrary queries against it — via an ad-hoc exploration view, via editing a panel, or by calling the API directly — and see everything that data source's single identity can see. - Hiding a dashboard, hiding a panel, filtering rows in a transformation, or restricting a folder does **not** restrict data. Those are navigation and presentation. - Consequently, if one data source can read every team's metrics, every Grafana user who can use it can read every team's metrics. ## Designs that actually enforce isolation 1. **One data source per tenant, plus data-source permissions.** Create a data source per team whose configuration pins that team's tenant (typically via the tenancy header or a scoped token), then restrict who may use each one. This puts enforcement in two places — the backend honours the tenant header, and Grafana restricts who can address that UID. Fine-grained data-source permissions are an Enterprise/Cloud capability; on open-source Grafana the equivalent is separate organisations or separate Grafana instances. 2. **Forward the user's identity.** Enable OAuth identity forwarding (or an equivalent per-user token) so the backend authorizes each query against the requesting human. This is the only design where Grafana is not the trust boundary — the backend is — and it is the right answer whenever the backend already has per-user authorization. Its costs: the backend must accept and validate those tokens, token lifetime and refresh become part of the query path, and anything evaluated *without* a user — alert rules, scheduled reports, caching — has no user token and therefore needs a separate service identity anyway. 3. **Separate Grafana organisations or instances per tenant.** Coarse, operationally heavier, but unambiguous — and the standard fallback where fine-grained permissions are unavailable. ## Practical checks worth naming - "Save & test" verifies reachability and that the credentials authenticate. It proves nothing about what rows or series the identity may read, and nothing about tenancy. - Grant the data source's identity the least privilege it needs: read-only, scoped to the intended tenant or database, never an administrative account. - Treat TLS skip-verify as an outage waiting to become a compromise; fix trust instead by supplying the CA. - Grafana holds many credentials in one place, which makes it a high-value target: protect its admin roles and its configuration API as carefully as you protect the backends themselves.