Plan your RBAC rollout strategy

An RBAC rollout strategy helps you determine how you want to implement RBAC prior to assigning RBAC roles to users and teams.

Your rollout strategy should help you answer the following questions:

• Should I assign basic roles to users, or should I assign fixed roles or custom roles to users?
• When should I create custom roles?
• To which entities should I apply fixed and custom roles? Should I apply them to users, teams? Should I modify the basic roles permissions instead?
• Which approach should I use when assigning roles? Should I use the Grafana UI, provisioning, or the API?

As a first step in determining your permissions rollout strategy, we recommend that you become familiar with basic role and fixed role definitions. In addition to assigning fixed roles to any user and team, you can also modify basic roles permissions, which changes what a Viewer, Editor, or Admin can do. This flexibility means that there are many combinations of role assignments for you to consider. If you have a large number of Grafana users and teams, we recommend that you make a list of which fixed roles you might want to use.

To learn more about basic roles and fixed roles, refer to the following documentation:

• Fixed role definitions

RBAC is a flexible and powerful feature with many possible permissions assignment combinations available. Consider the follow guidelines when assigning permissions to users and teams.

• Assign roles to users when you have a one-off scenario where a small number of users require access to a resource or when you want to assign temporary access. If you have a large number of users, this approach can be difficult to manage as you scale your use of Grafana. For example, a member of your IT department might need the and fixed:licensing:writer roles so that they can manage your Grafana Enterprise license.

• Assign roles to teams when you have a subset of users that align to your organizational structure, and you want all members of the team to have the same level of access. For example, all members of a particular engineering team might need the fixed:reports:reader and fixed:reports:writer roles to be able to manage reports.

  When you assign additional users to a team, the system automatically assigns permissions to those users.

You can take advantage of your current authentication provider to manage user and team permissions in Grafana. When you map users and teams to SAML and LDAP groups, you can synchronize those assignments with Grafana.

For example:

1. Map SAML, LDAP, or Oauth roles to Grafana basic roles (viewer, editor, or admin).

3. Within Grafana, assign RBAC permissions to users and teams.

Consider the following guidelines when you determine if you should modify basic roles or create custom roles.

• Modify basic roles when Grafana’s definitions of what viewers, editors, and admins can do does not match your definition of these roles. You can add or remove permissions from any basic role.

• Create custom roles when fixed role definitions don’t meet you permissions requirements. For example, the fixed:dashboards:writer role allows users to delete dashboards. If you want some users or teams to be able to create and update but not delete dashboards, you can create a custom role with a name like custom:dashboards:creator that lacks the dashboards:delete permission.

Use any of the following methods to assign RBAC roles to users and teams.

• Grafana UI: Use the Grafana UI when you want to assign a limited number of RBAC roles to users and teams. The UI contains a role picker that you can use to select roles.
• Grafana HTTP API: Use the Grafana HTTP API if you would like to automate role assignment.
• Terraform: Use Terraform to assign and manage user and team role assignments if you use Terraform for provisioning.
• Grafana provisioning: Grafana provisioning provides a robust approach to assigning, removing, and deleting roles. Within a single YAML file you can include multiple role assignment and removal entries.

We’ve compiled the following permissions rollout scenarios based on current Grafana implementations.

Provide internal viewer employees with the ability to use Explore, but prevent external viewer contractors from using Explore

1. In Grafana, create a team with the name Internal employees.
2. Assign the fixed:datasources:querier role to the Internal employees team.
3. Add internal employees to the Internal employees team, or map them from a SAML, LDAP, or Oauth team using .
4. Assign the viewer role to both internal employees and contractors.

Limit viewer, editor, or admin permissions

1. .

1. Create an Alert Managers team, and assign that team all applicable Alerting fixed roles.
2. Add users to the Alert Managers team.
3. Remove all permissions with actions prefixed with alert. from the Viewer, Editor, and Admin basic roles.

Provide dashboards to users in two or more geographies

1. Create a folder for each geography, for example, create a US folder and an EU folder.
2. Add dashboards to each folder.
3. Use folder permissions to add US-based users as Editors to the US folder and assign EU-based users as Editors to the EU folder.

Create a custom role to access alerts in a specific folder

To see an alert rule in Grafana, the user must have read access to the folder that stores the alert rule, permission to read alerts in the folder, and permission to query all data sources that the rule uses.

The API command in this example is based on the following:

• A Test-Folder with ID 92
• Two data sources: with UID _oAfGYUnk, and DS2 with UID YYcBGYUnk
• An alert rule that is stored in Test-Folder and queries the two data sources.

The following request creates a custom role that includes permissions to access the alert rule:

• Add the fixed:roles:writer role permissions to the basic:editor role using the role > from list of your provisioning file:

• Or add the following permissions to the basic:editor role, using provisioning or the RBAC HTTP API:

Enable viewers to create reports

If you want your Viewers to create reports, update the Viewer basic role permissions. There are two ways to achieve this:

• Add the fixed:reports:writer role permissions to the basic:viewer role using the role > from list of your provisioning file:

• Add the following permissions to the basic:viewer role, using provisioning or the :

Prevent a Grafana Admin from creating and inviting users

To prevent a Grafana Admin from creating users and inviting them to join an organization, you must . The permissions to remove are:

There are two ways to achieve this:

• Use the role > from list and permission > state option of your provisioning file:

• Or use RBAC HTTP API.

By default, Viewers, Editors and Admins have access to all App Plugins that their organization role allows them to access. To change this default behavior and prevent Viewers from accessing an App plugin, you must update a basic role’s permissions.

In this example, three App plugins have been installed and enabled:

By default, Viewers will hence be able to see both, On Call and Kentik Connect Pro App plugins. If you want to revoke their access to the On Call App plugin, you need to:

1. Remove the permission to access all application plugins:

2. Grant the permission to access the Kentik Connect Pro App plugin only:

   Action	Scope
   plugins.app:access	plugins:id:kentik-connect-app

Here are two ways to achieve this:

• Or use .