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

Authentication, roles, and resource permissions

Review user identity, organization or stack scope, resource permissions, and edition-specific access controls without mistaking dashboard visibility for data isolation.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish authentication from authorization.
Identify basic roles, teams, and resource scope.
Label Enterprise and Cloud RBAC capabilities explicitly.

Login identity is the beginning of the access question

Authentication establishes who is signing in through the configured mechanism, while authorization controls allowed actions and resource scope. Supported login and SSO capabilities vary by provider, edition, hosting, and version; do not present an Enterprise or Cloud capability as universal OSS behavior. Review identity mapping, group synchronization, session lifecycle, and the actual source of roles. A successful login does not prove the intended organization, team, or permission assignment. Keep account administration and access changes within the organization’s authorized process; this course creates and inspects no identity or account.

Separate basic roles from resource-specific grants

Basic organization roles, teams, dashboard or folder permissions, and available RBAC features participate in the actual access model. The fixed documentation distinguishes OSS capabilities from additional Enterprise permission controls; Cloud offerings need their own entitlement and configuration review. Team membership can simplify grants but is not proof of least privilege. A user can belong to several groups or teams, so inspect effective permissions rather than one visible role label. Keep server administration, organization administration, resource editing, and data-source query rights as separate questions instead of assuming one dashboard permission describes all of them.

Dashboard restrictions do not automatically restrict source queries

The pinned roles documentation describes default data-source querying as broader than the set of linked dashboards, with additional data-source permission capabilities available under documented editions. Therefore, hiding a panel, folder, or variable is not a tenant-isolation strategy. Review the trusted backend’s authorization and Grafana’s supported source-access controls together. A shared credential can query a broad backend scope even when the UI shows one route. Define what the reader may query, not only which saved page they can open. Never use a descriptive route or team field as an authorization claim.

Write intended actions before choosing the control

The editorial JSON records an intended read-only synthetic identity and separately names dashboard and data scope. It is not Grafana RBAC syntax, an API payload, or a permission grant. The local action check illustrates why read does not imply edit in a declared toy policy; it cannot reproduce effective Grafana permissions, inheritance, or edition behavior. A real review needs both positive and negative cases through the authorized mechanism. Include direct source querying and API or service-account paths where relevant, because a narrow browser workflow alone cannot establish the full access boundary.

json Editorial access-intent record

{"identity":"synthetic-transit-reader","intended_actions":["read-view"],"dashboard_scope":"transit-lab-folder","data_scope":"separately-enforced-lab-data"}

The fields are a teaching contract, not Grafana permission identifiers. The record grants no role, membership, token, or source access.

python Offline intended-action check

allowed_actions = {"read-view"}
for action in ["read-view", "edit-view", "query-all-data"]:
    print(action, action in allowed_actions)

Expected output

read-view True
edit-view False
query-all-data False

The fixed set is the entire toy policy. It performs no Grafana authentication, authorization, inheritance calculation, or account inspection.

Verify effective scope without exposing secrets

An authorized access review should record identity source, effective grants, resource scope, edition, version, and expected allow and deny outcomes. Do not paste tokens, session material, private usernames, or real access lists into a public lesson. Service accounts and their tokens need reviewed scope, lifecycle, and ownership; their permissions are not inferred from a dashboard title. This lesson parses no real policy and executes only a fixed set-membership check. It changes no role, team, folder, authentication setting, token, or account and claims no security validation of an installation.

Common errors and fixes

Successful login is called correct authorization

Why it happens: Identity proof was substituted for effective grants.
How to fix it: Review scope and resource actions separately.
Prevent it next time: Test expected allow and deny cases.

A folder restriction is called complete data isolation

Why it happens: Source query access and shared credentials were ignored.
How to fix it: Review the backend and supported source permissions.
Prevent it next time: Include non-dashboard query paths.

An Enterprise control is assumed available in OSS

Why it happens: Edition and entitlement boundaries were omitted.
How to fix it: Check the selected version and product documentation.
Prevent it next time: Record required capabilities before implementation.

Check your understanding

1. Can a Viewer restricted from opening one dashboard be assumed unable to query its underlying source?

Show worked solution

No. Dashboard visibility and source-query authorization are separate. Review the default and configured behavior of the selected edition and the backend credential scope. Test the actual allowed paths under authorization rather than treating a hidden saved view as proof of data isolation.

2. What does the local action fixture establish about Grafana permissions?