Roles and permissions on Grafana Labs

Grafana Role-based access control (RBAC)

Fri, 03 Apr 2026 19:43:06 +0000

Role-based access control (RBAC)

Note
Available in Grafana Enterprise and Grafana Cloud.

RBAC provides a standardized way of granting, changing, and revoking access when it comes to viewing and modifying Grafana resources, such as dashboards, reports, and administrative settings.

About RBAC

Role-based access control (RBAC) provides a standardized way of granting, changing, and revoking access so that users can view and modify Grafana resources, such as users and reports. RBAC extends Grafana basic roles that are included in Grafana OSS, and enables more granular control of users’ actions.

By using RBAC you can provide users with permissions that extend the permissions available with basic roles. For example, you can use RBAC to:

Modify existing basic roles: for example, enable an editor to create reports
Assign fixed roles to users and teams: for example, grant an engineering team the ability to create data sources
Create custom roles: for example, a role that allows users to create and edit dashboards, but not delete them

RBAC roles contain multiple permissions, each of which has an action and a scope:

Role: fixed:datasources:reader
- Permission:
  - Action: datasources:read
  - Scope: datasources:*

For information on the RBAC API refer to RBAC API.

Basic roles

Basic roles are the standard roles that are available in Grafana OSS. If you have purchased a Grafana Enterprise license, you can still use basic roles.

Grafana includes the following basic roles:

Grafana administrator
Organization administrator
Editor
Viewer
None

Each basic role is comprised of a number of permissions. For example, the viewer basic role contains the following permissions among others:

Action: datasources.id:read, Scope: datasources:*: Enables the viewer to see the ID of a data source.
Action: orgs:read: Enables the viewer to see their organization details
Action: annotations:read, Scope: annotations:*: Enables the viewer to see annotations that other users have added to a dashboard.
Action: annotations:create, Scope: annotations:type:dashboard: Enables the viewer to add annotations to a dashboard.
Action: annotations:write, Scope: annotations:type:dashboard: Enables the viewer to modify annotations of a dashboard.
Action: annotations:delete, Scope: annotations:type:dashboard: Enables the viewer to remove annotations from a dashboard.

Note
You can’t have a Grafana user without a basic role assigned. The None role contains no permissions.

Basic role modification

You can use RBAC to modify the permissions associated with any basic role, which changes what viewers, editors, or admins can do. If you modify a basic role, the change is not propagated to the other basic roles. You can’t delete basic roles.

You can modify basic roles using the configuration file or with the RBAC API. Refer to Manage RBAC roles to learn how.

Note that:

You cannot use a service account to modify basic roles via the RBAC API. To update basic roles, you must be a Grafana administrator and use basic authentication with the request.
If you’re a Cloud customer, contact Support to reset roles.

Fixed roles

Grafana Enterprise includes the ability for you to assign discrete fixed roles to users, teams, and service accounts. This gives you fine-grained control over user permissions than you would have with basic roles alone. These roles are called “fixed” because you cannot change or delete fixed roles. You can also create custom roles of your own; see more information in the custom roles section below.

Assign fixed roles when the basic roles do not meet your permission requirements. For example, you might want a user with the basic viewer role to also edit dashboards. Or, you might want anyone with the editor role to also add and manage users. Fixed roles provide users more granular access to create, view, and update the following Grafana resources:

To learn more about the permissions you can grant for each resource, refer to RBAC role definitions.

Custom roles

If you are a Grafana Enterprise customer, you can create custom roles to manage user permissions in a way that meets your security requirements.

Custom roles contain unique combinations of permissions actions and scopes. An action defines the action a use can perform on a Grafana resource. For example, the teams.roles:read action allows a user to see a list of roles associated with each team.

A scope describes where an action can be performed. For example, the teams:id:1 scope restricts the user’s action to the team with ID 1. When paired with the teams.roles:read action, this permission prohibits the user from viewing the roles for teams other than team 1.

Consider creating a custom role when fixed roles do not meet your permissions requirements.

Custom role creation

You can use either of the following methods to create, assign, and manage custom roles:

Grafana provisioning: You can use a YAML file to configure roles. For more information about using provisioning to create custom roles, refer to Manage RBAC roles. For more information about using provisioning to assign RBAC roles to users or teams, refer to Assign RBAC roles.
RBAC API: As an alternative, you can use the Grafana HTTP API to create and manage roles. For more information about the HTTP API, refer to RBAC API.

Limitation

If you have created a folder with the name General or general, you cannot manage its permissions with RBAC.

If you set folder permissions for a folder named General or general, the system disregards the folder when RBAC is enabled.

Folder access control

Fri, 03 Apr 2026 19:43:06 +0000

Folder access control

Folders are the primary way to organize and control access to resources in Grafana. When you assign permissions to a folder, those permissions apply to all resources within that folder, including dashboards, alert rules, SLOs, and more.

This page explains how folder permissions work and how to use them effectively to manage access for teams and users.

Before you begin

You need Admin permission on a folder to manage its permissions
To create folders, you need the Folder Creator role or appropriate organization permissions
Folder permissions are available in all Grafana editions (OSS, Enterprise, and Cloud)

Caution
Folder limitations:

Folders can be nested up to 4 levels deep

Folder names cannot contain underscores (_) or percent signs (%)

Default permissions for new folders

How a folder is created determines its initial permissions:

Folders created in the UI are automatically granted: Admin role gets Admin permission, Editor role gets Edit permission, Viewer role gets View permission
Folders created via as-code (Terraform, API, provisioning) only have permissions explicitly defined in the configuration, plus Admin role gets Admin permission by default

How folder permissions work

Folder permissions follow a simple principle: a user’s effective access to a resource is determined by their folder permission level.

When you grant a user or team permission on a folder:

The permission applies to the folder itself
The permission cascades to all subfolders
The permission applies to all resources in those folders (dashboards, alert rules, etc.)

Permission levels

Folders support three permission levels. Each level includes all capabilities of the levels below it.

Permission	Folder capabilities	Resource capabilities
View	View folder and navigate its contents	View dashboards, read alert rules, read silences, read annotations, read library panels
Edit	Create subfolders, modify folder properties	Create and edit dashboards, create and write alert rules, create and write silences, create and write annotations, create and manage library panels
Admin	Delete folder, manage folder permissions	All Edit capabilities plus manage dashboard permissions

Detailed action breakdown

View permission grants:

folders:read - View the folder in navigation
dashboards:read - View dashboards in the folder
alert.rules:read - View alert rules in the folder
alert.silences:read - View alert silences
annotations:read - View annotations
library.panels:read - View library panels

Edit permission grants (in addition to View):

folders:write - Modify folder name and properties
folders:create - Create subfolders
dashboards:create - Create new dashboards
dashboards:write - Edit existing dashboards
dashboards:delete - Delete dashboards
alert.rules:create - Create new alert rules
alert.rules:write - Edit alert rules
alert.rules:delete - Delete alert rules
alert.silences:create - Create silences
alert.silences:write - Edit silences
annotations:create - Create annotations
annotations:write - Edit annotations
annotations:delete - Delete annotations
library.panels:create - Create library panels
library.panels:write - Edit library panels
library.panels:delete - Delete library panels

Admin permission grants (in addition to Edit):

folders:delete - Delete the folder
folders.permissions:read - View folder permissions
folders.permissions:write - Modify folder permissions
dashboards.permissions:read - View dashboard permissions
dashboards.permissions:write - Modify dashboard permissions

Permission inheritance

Permissions cascade from parent folders to child folders. A user with Edit permission on a parent folder automatically has Edit permission on all subfolders.

Production/                    # User has Edit permission here
├── Team A Dashboards/         # User inherits Edit permission
│   └── Service Metrics/       # User inherits Edit permission
└── Team B Dashboards/         # User inherits Edit permission

Note
You cannot grant a user lower permissions on a subfolder than they have on a parent folder. Permission inheritance always flows downward.

Resources that use folder permissions

The following resources are stored in folders and respect folder permissions:

Resource	How folder permissions apply
Dashboards	View/Edit/Admin directly controlled by folder permission
Subfolders	Inherit parent folder permissions, can add additional permissions
Alert rules	View/Edit controlled by folder permission
Alert silences	View/Create/Edit controlled by folder permission
Library panels	View/Create/Edit/Delete controlled by folder permission
SLOs	Folder permission + SLO role determines effective access (refer to Plugin permissions)
Annotations	Stored on dashboards; inherit permissions from the dashboard’s parent folder

Plugin permissions

Some Grafana Cloud plugins use a two-layer permission model where effective access is determined by both folder permissions and a plugin-specific role:

Effective plugin access = minimum(folder permission, plugin role)

For example, with SLOs:

A user with folder Edit permission and SLO Writer role can create and edit SLOs in that folder
A user with folder View permission and SLO Writer role can only view SLOs (limited by folder)
A user with folder Edit permission and SLO Reader role can only view SLOs (limited by plugin role)

For more information, refer to SLO access control.

Manage folder permissions

Folders are accessed through the Dashboards section in Grafana. You can manage permissions from the folder’s context menu or from within the folder view.

View current permissions

In the left navigation, click Dashboards.
Navigate to the folder you want to inspect.
Click the folder name to open it, or click the ⋮ menu next to the folder.
Select Manage permissions.

The permissions dialog shows all users, teams, and roles with access to this folder.

Add a permission

Open the folder’s Manage permissions dialog.
Click Add a permission.
Select who to grant access to:
- User - A specific user account
- Team - All members of a team
- Service Account - A service account for API or automation access
- Role - Users with a specific organization role (Viewer, Editor, Admin)
Select the permission level (View, Edit, or Admin).
Click Save.

Change a permission

Open the folder’s Manage permissions dialog.
Find the user, team, or role in the list.
Use the permission dropdown to select a new level.
The change saves automatically.

Remove a permission

Open the folder’s Manage permissions dialog.
Find the user, team, or role in the list.
Click the × button to remove their access.
Confirm the removal.

Warning
Removing a permission removes access to the folder and all its contents. The user or team will no longer see dashboards, alert rules, or other resources in that folder.

Design your folder structure to manage permissions

A well-designed folder structure makes permission management simpler. The recommended pattern is to create top-level folders for each team, with subfolders for organizing content:

SRE Team/                      # SRE team has Admin
├── Production Monitoring/     # Inherited Admin
├── On-Call Dashboards/        # Inherited Admin
└── Runbooks/                  # Inherited Admin

Platform Team/                 # Platform team has Admin
├── Infrastructure/            # Inherited Admin
└── Cost Tracking/             # Inherited Admin

Shared/                        # Everyone has View, specific teams have Edit
├── Company KPIs/              # Marketing team has Edit
└── Executive Dashboards/      # Leadership has View

This pattern provides:

Team ownership: Each team manages their own folder and contents
Clear boundaries: Resources are organized by responsibility
Collaboration: Shared folders enable cross-team visibility

For detailed guidance on folder organization patterns, including automation with Terraform and SCIM provisioning, refer to:

Manage dashboard permissions - Dashboard-level permission management
Configure multi-team access - Recommended folder structures for organizations
RBAC fixed roles - Enterprise folder-related RBAC roles
Alerting folder permissions - How folders control alert rule access
Team management - Create and manage teams for folder access

Roles and permissions on Grafana Labs

Grafana Role-based access control (RBAC)

Role-based access control (RBAC)

About RBAC

Basic roles

Basic role modification

Fixed roles

Custom roles

Custom role creation

Limitation

Folder access control

Folder access control

Before you begin

Default permissions for new folders

How folder permissions work

Permission levels

Detailed action breakdown

Permission inheritance

Resources that use folder permissions

Plugin permissions

Manage folder permissions

View current permissions

Add a permission

Change a permission

Remove a permission

Design your folder structure to manage permissions

Related documentation