Configure GitLab OAuth2 authentication

    You need to . Choose a descriptive Name, and use the following Redirect URI:

    where is the URL you use to connect to Grafana. Adjust it as needed if you don’t use HTTPS or if you use a different port; for instance, if you access Grafana at http://203.0.113.31:3000, you should use

      Finally, select read_api_as the_Scope_and submit the form. Note that if you’re not going to use GitLab groups for authorization (i.e. not setting allowed_groups, see below), you can select_read_user instead of read_api_as the_Scope, thus giving a more restricted access to your GitLab API.

      You’ll get an Application Id and a Secret in return; we’ll call them GITLAB_APPLICATION_ID and GITLAB_SECRET respectively for the rest of this section.

      Enable GitLab in Grafana

      Add the following to your Grafana configuration file to enable GitLab authentication:

      You may have to set the root_url option of [server] for the callback URL to be correct. For example in case you are serving Grafana behind a proxy.

      Restart the Grafana backend for your changes to take effect.

      With allow_sign_up set to false, only existing users will be able to login using their GitLab account, but with allow_sign_up set to , any user who can authenticate on GitLab will be able to login on your Grafana instance; if you use the public gitlab.com, it means anyone in the world would be able to login on your Grafana instance.

      You can limit access to only members of a given group or list of groups by setting the allowed_groups option.

      To limit access to authenticated users that are members of one or more GitLab groups, set allowed_groups to a comma- or space-separated list of groups. For instance, if you want to only give access to members of the example group, set

      1. allowed_groups = example

      If you want to also give access to members of the subgroup bar, which is in the group foo, set

      Note that in GitLab, the group or subgroup name doesn’t always match its display name, especially if the display name contains spaces or special characters. Make sure you always use the group or subgroup name as it appears in the URL of the group or subgroup.

      Here’s a complete example with allow_sign_up enabled, with access limited to the example and foo/bar groups. The example also promotes all GitLab Admins to Grafana Admins:

      1. [auth.gitlab]
      2. enabled = true
      3. allow_sign_up = true
      4. client_id = GITLAB_APPLICATION_ID
      5. client_secret = GITLAB_SECRET
      6. auth_url = https://gitlab.com/oauth/authorize
      7. token_url = https://gitlab.com/oauth/token
      8. api_url = https://gitlab.com/api/v4
      9. allowed_groups = example, foo/bar
      10. role_attribute_path = is_admin && 'Admin' || 'Viewer'

      You can use GitLab OAuth to map roles. During mapping, Grafana checks for the presence of a role using the JMESPath specified via the role_attribute_path configuration option.

      An example Query could look like the following:

      This allows every GitLab Admin to be an Admin in Grafana.

      Map roles using groups

      Groups can also be used to map roles. Group name (lowercased and unique) is used instead of display name for identifying groups

      For instance, if you have a group with display name ‘Example-Group’ you can use the following snippet to ensure those members inherit the role ‘Editor’.

      1. role_attribute_path = contains(groups[*], 'example-group') && 'Editor' || 'Viewer'

      Note: If a match is found in other fields, groups will be ignored.

      With Team Sync you can map your GitLab groups to teams in Grafana so that your users will automatically be added to the correct teams.