Configure security on Grafana Labs

Plan your IAM integration strategy

Fri, 13 Mar 2026 14:43:40 -0400

Plan your IAM integration strategy

This section describes the decisions you should make when using an Identity and Access Management (IAM) provider to manage access to Grafana. IAM ensures that users have secure access to sensitive data and other resources, simplifying user management and authentication.

Benefits of integrating with an IAM provider

Integrating with an IAM provider provides the following benefits:

User management: By providing Grafana access to your current user management system, you eliminate the overhead of replicating user information and instead have centralized user management for users’ roles and permissions to Grafana resources.
Security: Many IAM solutions provide advanced security features such as multi-factor authentication, RBAC, and audit trails, which can help to improve the security of your Grafana installation.
SSO: Properly setting up Grafana with your current IAM solution enables users to access Grafana with the same credentials they use for other applications.
Scalability: User additions and updates in your user database are immediately reflected in Grafana.

In order to plan an integration with Grafana, assess your organization’s current needs, requirements, and any existing IAM solutions being used. This includes thinking about how roles and permissions will be mapped to users in Grafana and how users can be grouped to access shared resources.

Internal vs external users

As a first step, determine how you want to manage users who will access Grafana.

Do you already use an identity provider to manage users? If so, Grafana might be able to integrate with your identity provider through one of our IdP integrations. Refer to Configure authentication documentation for the list of supported providers.

If you are not interested in setting up an external identity provider, but still want to limit access to your Grafana instance, consider using Grafana’s basic authentication.

Finally, if you want your Grafana instance to be accessible to everyone, you can enable anonymous access to Grafana. For information, refer to the anonymous authentication documentation.

Ways to organize users

Organize users in subgroups that are sensible to the organization. For example:

Security: Different groups of users or customers should only have access to their intended resources.
Simplicity: Reduce the scope of dashboards and resources available.
Cost attribution: Track and bill costs to individual customers, departments, or divisions.
Customization: Each group of users could have a personalized experience like different dashboards or theme colors.

Users in Grafana teams

You can organize users into teams and assign them roles and permissions reflecting the current organization. For example, instead of assigning five users access to the same dashboard, you can create a team of those users and assign dashboard permissions to the team.

A user can belong to multiple teams and be a member or an administrator for a given team. Team members inherit permissions from the team but cannot edit the team itself. Team administrators can add members to a team and update its settings, such as the team name, team members, roles assigned, and UI preferences.

Teams are a perfect solution for working with a subset of users. Teams can share resources with other teams.

Users in Grafana organizations

Grafana organizations allow complete isolation of resources, such as dashboards and data sources. Users can be members of one or several organizations, and they can only access resources from an organization they belong to.

Having multiple organizations in a single instance of Grafana lets you manage your users in one place while completely separating resources.

Organizations provide a higher measure of isolation within Grafana than teams do and can be helpful in certain scenarios. However, because organizations lack the scalability and flexibility of teams and folders, we do not recommend using them as the default way to group users and resources.

Note that Grafana Cloud does not support having more than 1 organizations per instance.

Choosing between teams and organizations

Grafana teams and Grafana organizations serve similar purposes in the Grafana platform. Both are designed to help group users and manage and control access to resources.

Teams provide more flexibility, as resources can be accessible by multiple teams, and team creation and management are simple.

In contrast, organizations provide more isolation than teams, as resources cannot be shared between organizations. They are more difficult to manage than teams, as you must create and update resources for each organization individually. Organizations cater to bigger companies or users with intricate access needs, necessitating complete resource segregation.

Access to external systems

Consider the need for machine-to-machine M2M communications. If a system needs to interact with Grafana, ensure it has proper access.

Consider the following scenarios:

Schedule reports: Generate reports periodically from Grafana through the reporting API and have them delivered to different communications channels like email, instant messaging, or keep them in a shared storage.

Define alerts: Define alert rules to be triggered when a specific condition is met. Route alert notifications to different teams according to your organization’s needs.

Provisioning file: Provisioning files can be used to automate the creation of dashboards, data sources, and other resources.

These are just a few examples of how Grafana can be used in M2M scenarios. The platform is highly flexible and can be used in various M2M applications, making it a powerful tool for organizations seeking insights into their systems and devices.

Service accounts

You can use a service account to run automated workloads in Grafana, such as dashboard provisioning, configuration, or report generation. Create service accounts and service accounts tokens to authenticate applications, such as Terraform, with the Grafana API.

Note
Service accounts will eventually replace API keys as the primary way to authenticate applications that interact with Grafana.

A common use case for creating a service account is to perform operations on automated or triggered tasks. You can use service accounts to:

Schedule reports for specific dashboards to be delivered on a daily/weekly/monthly basis
Define alerts in your system to be used in Grafana
Set up an external SAML authentication provider
Interact with Grafana without signing in as a user

In Grafana Enterprise, you can also use service accounts in combination with role-based access control to grant very specific permissions to applications that interact with Grafana.

Note
Service accounts can only act in the organization they are created for. We recommend creating service accounts in each organization if you have the same task needed for multiple organizations.

The following video shows how to migrate from API keys to service accounts.

Service account tokens

To authenticate with Grafana’s HTTP API, a randomly generated string known as a service account token can be used as an alternative to a password.

When a service account is created, it can be linked to multiple access tokens. These service access tokens can be utilized in the same manner as API keys, providing a means to programmatically access Grafana HTTP API.

You can create multiple tokens for the same service account. You might want to do this if:

Multiple applications use the same permissions, but you want to audit or manage their actions separately.
You need to rotate or replace a compromised token.

Note
In Grafana’s audit logs it will still show up as the same service account.

Service account access tokens inherit permissions from the service account.

API keys

Note
If you use Grafana v8.5 or newer, you should use service accounts instead of API keys. API keys will be deprecated in the near future. For more information, refer to Grafana service accounts.

You can use Grafana API keys to interact with data sources via HTTP APIs.

How to work with roles?

Grafana roles control the access of users and service accounts to specific resources and determine their authorized actions.

You can assign roles through the user interface or APIs, establish them through Terraform, or synchronize them automatically via an external IAM provider.

What are roles?

Within an organization, Grafana has established three primary organization roles - organization administrator, editor, and viewer - which dictate the user’s level of access and permissions, including the ability to edit data sources or create teams. To be a member of any organization, every user must be assigned a role.

In addition, Grafana provides a server administrator role that grants access to and enables interaction with resources that affect the entire instance, including organizations, users, and server-wide settings. This particular role can only be accessed by users of self-hosted Grafana instances. It is a significant role intended for the administrators of the Grafana instance.

What are permissions?

Each role consists of a set of permissions that determine the tasks a user can perform in the system. For example, the Admin role includes permissions that let an administrator create and delete users.

Grafana allows for precise permission settings on both dashboards and folders, giving you the ability to control which users and teams can view, edit, and administer them. For example, you might want a certain viewer to be able to edit a dashboard. While that user can see all dashboards, you can grant them access to update only one of them.

In Grafana Enterprise, you can also grant granular permissions for data sources to control who can query and edit them.

Dashboard, folder, and data source permissions can be set through the UI or APIs or provisioned through Terraform.

Role-based access control

Note
Available in Grafana Enterprise and Grafana Cloud.

If you think that the basic organization and server administrator roles are too limiting, it might be beneficial to employ role-based access control (RBAC). RBAC is a flexible approach to managing user access to Grafana resources, including users, data sources, and reports. It enables easy granting, changing, and revoking of read and write access for users.

RBAC comes with pre-defined roles, such as data source writer, which allows updating, reading, or querying all data sources. You can assign these roles to users, teams, and service accounts.

In addition, RBAC empowers you to generate personalized roles and modify permissions authorized by the standard Grafana roles.

User synchronization between Grafana and identity providers

When connecting Grafana to an identity provider, it’s important to think beyond just the initial authentication setup. You should also think about the maintenance of user bases and roles. Using Grafana’s team and role synchronization features ensures that updates you make to a user in your identity provider will be reflected in their role assignment and team memberships in Grafana.

Team sync

Team sync is a feature that allows you to synchronize teams or groups from your authentication provider with teams in Grafana. This means that users of specific teams or groups in LDAP, OAuth, or SAML will be automatically added or removed as members of corresponding teams in Grafana. Whenever a user logs in, Grafana will check for any changes in the teams or groups of the authentication provider and update the user’s teams in Grafana accordingly. This makes it easy to manage user permissions across multiple systems.

Note
Available in Grafana Enterprise and Grafana Cloud Advanced.

Note
Team synchronization occurs only when a user logs in. However, if you are using LDAP, it is possible to enable active background synchronization. This allows for the continuous synchronization of teams.

Role Sync

Grafana can synchronize basic roles from your authentication provider by mapping attributes from the identity provider to the user role in Grafana. This means that users with specific attributes, like role, team, or group membership in LDAP, OAuth, or SAML, will be automatically assigned the corresponding role in Grafana. Whenever a user logs in, Grafana will check for any changes in the user information retrieved from the authentication provider and update the user’s role in Grafana accordingly.

Organization sync

Organization sync is the process of binding all the users from an organization in Grafana. This delegates the role of managing users to the identity provider. This way, there’s no need to manage user access from Grafana because the identity provider will be queried whenever a new user tries to log in.

With organization sync, users from identity provider groups can be assigned to corresponding Grafana organizations. This functionality is similar to role sync but with the added benefit of specifying the organization that a user belongs to for a particular identity provider group. Please note that this feature is only available for self-hosted Grafana instances, as Cloud Grafana instances have a single organization limit.

Note
Organization sync is currently only supported for SAML and LDAP.

Note
You don’t need to invite users through Grafana when syncing with Organization sync.

Note
Currently, only basic roles can be mapped via Organization sync.

Configure authentication

Fri, 13 Mar 2026 14:43:40 -0400

Configure authentication

Grafana provides many ways to authenticate users. Some authentication integrations also enable syncing user permissions and org memberships.

The following table shows all supported authentication providers and the features available for them. Team sync and active sync are only available in Grafana Enterprise.

Provider	Support	Role mapping	Team sync (Enterprise only)	Active sync (Enterprise only)
Auth Proxy	v2.1+	-	v6.3+	-
Azure AD OAuth	v6.7+	v6.7+	v6.7+	-
Generic OAuth	v4.0+	v6.5+	-	-
GitHub OAuth	v2.0+	-	v6.3+	-
GitLab OAuth	v5.3+	-	v6.4+	-
Google OAuth	v2.0+	-	-	-
JWT	v8.0+	-	-	-
LDAP	v2.1+	v2.1+	v5.3+	v6.3+
Okta OAuth	v7.0+	v7.0+	v7.0+	-
SAML (Enterprise only)	v6.3+	v7.0+	v7.0+	-

Configuring multiple identity providers

Grafana allows you to configure more than one authentication provider, however it is not possible to configure the same type of authentication provider twice. For example, you can have SAML (Enterprise only) and Generic OAuth configured, but you can not have two different Generic OAuth configurations.

Note: Grafana does not support multiple identity providers resolving the same user. Ensure there are no user account overlaps between the different providers

In scenarios where you have multiple identity providers of the same type, there are a couple of options:

Use different Grafana instances each configured with a given identity provider.
Check if the identity provider supports account federation. In such cases, you can configure it once and let your identity provider federate the accounts from different providers.
If SAML is supported by the identity provider, you can configure one Generic OAuth and one SAML (Enterprise only).

Grafana Auth

Grafana of course has a built in user authentication system with password authentication enabled by default. You can disable authentication by enabling anonymous access. You can also hide the login form and only allow login through an auth provider (listed above). There are also options for allowing self sign up.

The following applies when using Grafana’s built in user authentication, LDAP (without Auth proxy) or OAuth integration.

Grafana uses short-lived tokens as a mechanism for verifying authenticated users. These short-lived tokens are rotated on an interval specified by token_rotation_interval_minutes for active authenticated users.

Inactive authenticated users will remain logged in for a duration specified by login_maximum_inactive_lifetime_duration. This means that a user can close a Grafana window and return before now + login_maximum_inactive_lifetime_duration to continue their session. This is true as long as the time since last user login is less than login_maximum_lifetime_duration.

Remote logout

You can logout from other devices by removing login sessions from the bottom of your profile page. If you are a Grafana admin user, you can also do the same for any user from the Server Admin / Edit User view.

Settings

Example:

[auth]

# Login cookie name
login_cookie_name = grafana_session

# The maximum lifetime (duration) an authenticated user can be inactive before being required to login at next visit. Default is 7 days (7d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month). The lifetime resets at each successful token rotation (token_rotation_interval_minutes).
login_maximum_inactive_lifetime_duration =

# The maximum lifetime (duration) an authenticated user can be logged in since login time before being required to login. Default is 30 days (30d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month).
login_maximum_lifetime_duration =

# How often should auth tokens be rotated for authenticated users when being active. The default is every 10 minutes.
token_rotation_interval_minutes = 10

# The maximum lifetime (seconds) an API key can be used. If it is set all the API keys should have limited lifetime that is lower than this value.
api_key_max_seconds_to_live = -1

# Enforce user lookup based on email instead of the unique ID provided by the IdP.
oauth_allow_insecure_email_lookup = false

Anonymous authentication

You can make Grafana accessible without any login required by enabling anonymous access in the configuration file.

Example:

[auth.anonymous]
enabled = true

# Organization name that should be used for unauthenticated users
org_name = Main Org.

# Role for unauthenticated users, other valid values are `Editor` and `Admin`
org_role = Viewer

If you change your organization name in the Grafana UI, this setting needs to be updated to match the new name.

Basic authentication

Basic auth is enabled by default and works with the built-in Grafana user-password authentication system and LDAP authentication integration.

To disable basic auth:

[auth.basic]
enabled = false

Hide the Grafana login form using the below configuration settings.

[auth]
disable_login_form = true

Enable email lookup

Enable user lookup based on email in addition to using unique ID provided by IdPs.

By default, Grafana relies on the user unique ID provided by the identity provider. Looking up users by email can be safe for some identity providers (for example, when they are single tenants and unique non-editable, validated emails are provided), as well as in some infrastructures.

We strongly recommend against enabling email lookups, however it is possible to do with the following configuration.

[auth]
oauth_allow_insecure_email_lookup = true

Set to true to attempt login with specific OAuth provider automatically, skipping the login screen. This setting is ignored if multiple auth providers are configured to use auto login. Defaults to false.

[auth.generic_oauth]
auto_login = true

To sign in with a username and password and avoid automatic OAuth login, add the disableAutoLogin parameter to your login URL. For example: grafana.example.com/login?disableAutoLogin or grafana.example.com/login?disableAutoLogin=true

Set the option detailed below to true to hide sign-out menu link. Useful if you use an auth proxy or JWT authentication.

[auth]
disable_signout_menu = true

URL redirect after signing out

URL to redirect the user to after signing out from Grafana. This can for example be used to enable signout from OAuth provider.

[auth]
signout_redirect_url =

Protected roles

Note
Available in Grafana Enterprise and Grafana Cloud.

By default, after you configure an authorization provider, Grafana will adopt existing users into the new authentication scheme. For example, if you have created a user with basic authentication having the login jsmith@example.com, then set up SAML authentication where jsmith@example.com is an account, the user’s authentication type will be changed to SAML if they perform a SAML sign-in.

You can disable this user adoption for certain roles using the protected_roles property:

[auth.security]
protected_roles = server_admins org_admins

The value of protected_roles should be a list of roles to protect, separated by spaces. Valid roles are viewers, editors, org_admins, server_admins, and all (a superset of the other roles).

Configure database encryption

Fri, 13 Mar 2026 14:43:40 -0400

Configure database encryption

Grafana’s database contains secrets, which are used to query data sources, send alert notifications, and perform other functions within Grafana.

Grafana encrypts these secrets before they are written to the database, by using a symmetric-key encryption algorithm called Advanced Encryption Standard (AES). These secrets are signed using a secret key that you can change when you configure a new Grafana instance.

Note
Grafana v9.0 and newer use envelope encryption by default, which adds a layer of indirection to the encryption process that introduces an implicit breaking change for older versions of Grafana.

For further details about how to operate a Grafana instance with envelope encryption, see the Operational work section.

Note
In Grafana Enterprise, you can also encrypt secrets in AES-GCM (Galois/Counter Mode) instead of the default AES-CFB (Cipher FeedBack mode).

Envelope encryption

Note
Since Grafana v9.0, you can turn envelope encryption off by adding the feature toggle disableEnvelopeEncryption to your Grafana configuration.

Instead of encrypting all secrets with a single key, Grafana uses a set of keys called data encryption keys (DEKs) to encrypt them. These data encryption keys are themselves encrypted with a single key encryption key (KEK), configured through the secret_key attribute in your Grafana configuration or by Encrypting your database with a key from a key management service (KMS).

Implicit breaking change

Envelope encryption introduces an implicit breaking change to versions of Grafana prior to v9.0, because it changes how secrets stored in the Grafana database are encrypted. Grafana administrators can upgrade to Grafana v9.0 with no action required from the database encryption perspective, but must be extremely careful if they need to roll an upgrade back to Grafana v8.5 or earlier because secrets created or modified after upgrading to Grafana v9.0 can’t be decrypted by previous versions.

Grafana v8.5 implemented envelope encryption behind an optional feature toggle. Grafana administrators who need to downgrade to Grafana v8.5 can enable envelope encryption as a workaround by adding the feature toggle envelopeEncryption to the Grafana configuration.

Operational work

From the database encryption perspective, Grafana administrators can:

Re-encrypt secrets: re-encrypt secrets with envelope encryption and a fresh data key.
Roll back secrets: decrypt secrets encrypted with envelope encryption and re-encrypt them with legacy encryption.
Re-encrypt data keys: re-encrypt data keys with a fresh key encryption key and a KMS integration.
Rotate data keys: disable active data keys and stop using them for encryption in favor of a fresh one.

Re-encrypt secrets

You can re-encrypt secrets in order to:

Move already existing secrets’ encryption forward from legacy to envelope encryption.
Re-encrypt secrets after a data keys rotation.

To re-encrypt secrets, use the Grafana CLI by running the grafana cli admin secrets-migration re-encrypt command or the /encryption/reencrypt-secrets endpoint of the Grafana Admin API. It’s safe to run more than once, more recommended under maintenance mode.

Roll back secrets

You can roll back secrets encrypted with envelope encryption to legacy encryption. This might be necessary to downgrade to Grafana versions prior to v9.0 after an unsuccessful upgrade.

To roll back secrets, use the Grafana CLI by running the grafana cli admin secrets-migration rollback command or the /encryption/rollback-secrets endpoint of the Grafana Admin API. It’s safe to run more than once, more recommended under maintenance mode.

Re-encrypt data keys

You can re-encrypt data keys encrypted with a specific key encryption key (KEK). This allows you to either re-encrypt existing data keys with a new KEK version or to re-encrypt them with a completely different KEK.

To re-encrypt data keys, use the Grafana CLI by running the grafana cli admin secrets-migration re-encrypt-data-keys command or the /encryption/reencrypt-data-keys endpoint of the Grafana Admin API. It’s safe to run more than once, more recommended under maintenance mode.

Rotate data keys

You can rotate data keys to disable the active data key and therefore stop using them for encryption operations. For high-availability setups, you might need to wait until the data keys cache’s time-to-live (TTL) expires to ensure that all rotated data keys are no longer being used for encryption operations.

New data keys for encryption operations are generated on demand.

Note
Data key rotation does not implicitly re-encrypt secrets. Grafana will continue to use rotated data keys to decrypt secrets still encrypted with them. To completely stop using rotated data keys for both encryption and decryption, see secrets re-encryption.

To rotate data keys, use the /encryption/rotate-data-keys endpoint of the Grafana Admin API. It’s safe to call more than once, more recommended under maintenance mode.

Encrypting your database with a key from a key management service (KMS)

If you are using Grafana Enterprise, you can integrate with a key management service (KMS) provider, and change Grafana’s cryptographic mode of operation from AES-CFB to AES-GCM.

You can choose to encrypt secrets stored in the Grafana database using a key from a KMS, which is a secure central storage location that is designed to help you to create and manage cryptographic keys and control their use across many services. When you integrate with a KMS, Grafana does not directly store your encryption key. Instead, Grafana stores KMS credentials and the identifier of the key, which Grafana uses to encrypt the database.

Grafana integrates with the following key management services:

Changing your encryption mode to AES-GCM

Grafana encrypts secrets using Advanced Encryption Standard in Cipher FeedBack mode (AES-CFB). You might prefer to use AES in Galois/Counter Mode (AES-GCM) instead, to meet your company’s security requirements or in order to maintain consistency with other services.

To change your encryption mode, update the algorithm value in the [security.encryption] section of your Grafana configuration file. For further details, refer to Enterprise configuration.

Audit a Grafana instance

Fri, 13 Mar 2026 14:43:40 -0400

Audit a Grafana instance

Auditing allows you to track important changes to your Grafana instance. By default, audit logs are logged to file but the auditing feature also supports sending logs directly to Loki.

Only API requests or UI actions that trigger an API request generate an audit log.

Note
Available in Grafana Enterprise version 7.3 and later, and Grafana Cloud.

Audit logs

Audit logs are JSON objects representing user actions like:

Modifications to resources such as dashboards and data sources.
A user failing to log in.

Format

Audit logs contain the following fields. The fields followed by * are always available, the others depend on the type of action logged.

Field name	Type	Description
`timestamp`*	string	The date and time the request was made, in coordinated universal time (UTC) using the RFC3339 format.
`user`*	object	Information about the user that made the request. Either one of the `UserID` or `ApiKeyID` fields will contain content if `isAnonymous=false`.
`user.userId`	number	ID of the Grafana user that made the request.
`user.orgId`*	number	Current organization of the user that made the request.
`user.orgRole`	string	Current role of the user that made the request.
`user.name`	string	Name of the Grafana user that made the request.
`user.tokenId`	number	ID of the user authentication token.
`user.apiKeyId`	number	ID of the Grafana API key used to make the request.
`user.isAnonymous`*	boolean	If an anonymous user made the request, `true`. Otherwise, `false`.
`action`*	string	The request action. For example, `create`, `update`, or `manage-permissions`.
`request`*	object	Information about the HTTP request.
`request.params`	object	Request’s path parameters.
`request.query`	object	Request’s query parameters.
`request.body`	string	Request’s body. Filled with `<non-marshalable format>` when it isn’t a valid JSON.
`result`*	object	Information about the HTTP response.
`result.statusType`	string	If the request action was successful, `success`. Otherwise, `failure`.
`result.statusCode`	number	HTTP status of the request.
`result.failureMessage`	string	HTTP error message.
`result.body`	string	Response body. Filled with `<non-marshalable format>` when it isn’t a valid JSON.
`resources`	array	Information about the resources that the request action affected. This field can be null for non-resource actions such as `login` or `logout`.
`resources[x].id`*	number	ID of the resource.
`resources[x].type`*	string	The type of the resource that was logged: `alert`, `alert-notification`, `annotation`, `api-key`, `auth-token`, `dashboard`, `datasource`, `folder`, `org`, `panel`, `playlist`, `report`, `team`, `user`, or `version`.
`requestUri`*	string	Request URI.
`ipAddress`*	string	IP address that the request was made from.
`userAgent`*	string	Agent through which the request was made.
`grafanaVersion`*	string	Current version of Grafana when this log is created.
`additionalData`	object	Additional information that can be provided about the request.

The additionalData field can contain the following information:

Field name	Action	Description
`loginUsername`	`login`	Login used in the Grafana authentication form.
`extUserInfo`	`login`	User information provided by the external system that was used to log in.
`authTokenCount`	`login`	Number of active authentication tokens for the user that logged in.
`terminationReason`	`logout`	The reason why the user logged out, such as a manual logout or a token expiring.
`billing_role`	`billing-information`	The billing role associated with the billing information being sent.

Recorded actions

The audit logs include records about the following categories of actions. Each action is distinguished by the action and resources[...].type fields in the JSON record.

For example, creating an API key produces an audit log like this:

{
  "action": "create",
  "resources": [
    {
      "id": 1,
      "type": "api-key"
    }
  ],
  "timestamp": "2021-11-12T22:12:36.144795692Z",
  "user": {
    "userId": 1,
    "orgId": 1,
    "orgRole": "Admin",
    "username": "admin",
    "isAnonymous": false,
    "authTokenId": 1
  },
  "request": {
    "body": "{\"name\":\"example\",\"role\":\"Viewer\",\"secondsToLive\":null}"
  },
  "result": {
    "statusType": "success",
    "statusCode": 200,
    "responseBody": "{\"id\":1,\"name\":\"example\"}"
  },
  "resources": [
    {
      "id": 1,
      "type": "api-key"
    }
  ],
  "requestUri": "/api/auth/keys",
  "ipAddress": "127.0.0.1:54652",
  "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0",
  "grafanaVersion": "8.3.0-pre"
}

Some actions can only be distinguished by their requestUri fields. For those actions, the relevant pattern of the requestUri field is given.

Note that almost all these recorded actions are actions that correspond to API requests or UI actions that trigger an API request. Therefore, the action {"action": "email", "resources": [{"type": "report"}]} corresponds to the action when the user requests a report’s preview to be sent through email, and not the scheduled ones.

Sessions

Action	Distinguishing fields
Log in	`{"action": "login-AUTH-MODULE"}` *
Log out **	`{"action": "logout"}`
Force logout for user	`{"action": "logout-user"}`
Remove user authentication token	`{"action": "revoke-auth-token", "resources": [{"type": "auth-token"}, {"type": "user"}]}`
Create API key	`{"action": "create", "resources": [{"type": "api-key"}]}`
Delete API key	`{"action": "delete", "resources": [{"type": "api-key"}]}`

* Where AUTH-MODULE is the name of the authentication module: grafana, saml, ldap, etc.
** Includes manual log out, token expired/revoked, and SAML Single Logout.

Service accounts

Action	Distinguishing fields
Create service account	`{"action": "create", "resources": [{"type": "service-account"}]}`
Update service account	`{"action": "update", "resources": [{"type": "service-account"}]}`
Delete service account	`{"action": "delete", "resources": [{"type": "service-account"}]}`
Create service account token	`{"action": "create", "resources": [{"type": "service-account"}, {"type": "service-account-token"}]}`
Delete service account token	`{"action": "delete", "resources": [{"type": "service-account"}, {"type": "service-account-token"}]}`
Hide API keys	`{"action": "hide-api-keys"}`
Migrate API keys	`{"action": "migrate-api-keys"}`
Migrate API key	`{"action": "migrate-api-keys"}, "resources": [{"type": "api-key"}]}`

Access control

Action	Distinguishing fields
Create role	`{"action": "create", "resources": [{"type": "role"}]}`
Update role	`{"action": "update", "resources": [{"type": "role"}]}`
Delete role	`{"action": "delete", "resources": [{"type": "role"}]}`
Assign built-in role	`{"action": "assign-builtin-role", "resources": [{"type": "role"}, {"type": "builtin-role"}]}`
Remove built-in role	`{"action": "remove-builtin-role", "resources": [{"type": "role"}, {"type": "builtin-role"}]}`
Grant team role	`{"action": "grant-team-role", "resources": [{"type": "team"}]}`
Set team roles	`{"action": "set-team-roles", "resources": [{"type": "team"}]}`
Revoke team role	`{"action": "revoke-team-role", "resources": [{"type": "role"}, {"type": "team"}]}`
Grant user role	`{"action": "grant-user-role", "resources": [{"type": "role"}, {"type": "user"}]}`
Set user roles	`{"action": "set-user-roles", "resources": [{"type": "user"}]}`
Revoke user role	`{"action": "revoke-user-role", "resources": [{"type": "role"}, {"type": "user"}]}`
Set user permissions on folder	`{"action": "set-user-permissions-on-folder", "resources": [{"type": "folder"}, {"type": "user"}]}`
Set team permissions on folder	`{"action": "set-team-permissions-on-folder", "resources": [{"type": "folder"}, {"type": "team"}]}`
Set basic role permissions on folder	`{"action": "set-basic-role-permissions-on-folder", "resources": [{"type": "folder"}, {"type": "builtin-role"}]}`
Set user permissions on dashboard	`{"action": "set-user-permissions-on-dashboards", "resources": [{"type": "dashboard"}, {"type": "user"}]}`
Set team permissions on dashboard	`{"action": "set-team-permissions-on-dashboards", "resources": [{"type": "dashboard"}, {"type": "team"}]}`
Set basic role permissions on dashboard	`{"action": "set-basic-role-permissions-on-dashboards", "resources": [{"type": "dashboard"}, {"type": "builtin-role"}]}`
Set user permissions on team	`{"action": "set-user-permissions-on-teams", "resources": [{"type": "teams"}, {"type": "user"}]}`
Set user permissions on service account	`{"action": "set-user-permissions-on-service-accounts", "resources": [{"type": "service-account"}, {"type": "user"}]}`
Set user permissions on datasource	`{"action": "set-user-permissions-on-data-sources", "resources": [{"type": "datasource"}, {"type": "user"}]}`
Set team permissions on datasource	`{"action": "set-team-permissions-on-data-sources", "resources": [{"type": "datasource"}, {"type": "team"}]}`
Set basic role permissions on datasource	`{"action": "set-basic-role-permissions-on-data-sources", "resources": [{"type": "datasource"}, {"type": "builtin-role"}]}`

User management

Action	Distinguishing fields
Create user	`{"action": "create", "resources": [{"type": "user"}]}`
Update user	`{"action": "update", "resources": [{"type": "user"}]}`
Delete user	`{"action": "delete", "resources": [{"type": "user"}]}`
Disable user	`{"action": "disable", "resources": [{"type": "user"}]}`
Enable user	`{"action": "enable", "resources": [{"type": "user"}]}`
Update password	`{"action": "update-password", "resources": [{"type": "user"}]}`
Send password reset email	`{"action": "send-reset-email"}`
Reset password	`{"action": "reset-password"}`
Update permissions	`{"action": "update-permissions", "resources": [{"type": "user"}]}`
Send signup email	`{"action": "signup-email"}`
Click signup link	`{"action": "signup"}`
Reload LDAP configuration	`{"action": "ldap-reload"}`
Get user in LDAP	`{"action": "ldap-search"}`
Sync user with LDAP	`{"action": "ldap-sync", "resources": [{"type": "user"}]`

Team and organization management

Action	Distinguishing fields
Add team	`{"action": "create", "requestUri": "/api/teams"}`
Update team	`{"action": "update", "requestUri": "/api/teams/TEAM-ID"}`*
Delete team	`{"action": "delete", "requestUri": "/api/teams/TEAM-ID"}`*
Add external group for team	`{"action": "create", "requestUri": "/api/teams/TEAM-ID/groups"}`*
Remove external group for team	`{"action": "delete", "requestUri": "/api/teams/TEAM-ID/groups/GROUP-ID"}`*
Add user to team	`{"action": "create", "resources": [{"type": "user"}, {"type": "team"}]}`
Update team member permissions	`{"action": "update", "resources": [{"type": "user"}, {"type": "team"}]}`
Remove user from team	`{"action": "delete", "resources": [{"type": "user"}, {"type": "team"}]}`
Create organization	`{"action": "create", "resources": [{"type": "org"}]}`
Update organization	`{"action": "update", "resources": [{"type": "org"}]}`
Delete organization	`{"action": "delete", "resources": [{"type": "org"}]}`
Add user to organization	`{"action": "create", "resources": [{"type": "org"}, {"type": "user"}]}`
Change user role in organization	`{"action": "update", "resources": [{"type": "user"}, {"type": "org"}]}`
Remove user from organization	`{"action": "delete", "resources": [{"type": "user"}, {"type": "org"}]}`
Invite external user to organization	`{"action": "org-invite", "resources": [{"type": "org"}, {"type": "user"}]}`
Revoke invitation	`{"action": "revoke-org-invite", "resources": [{"type": "org"}]}`

* Where TEAM-ID is the ID of the affected team, and GROUP-ID (if present) is the ID of the external group.

Folder and dashboard management

Action	Distinguishing fields
Create folder	`{"action": "create", "resources": [{"type": "folder"}]}`
Update folder	`{"action": "update", "resources": [{"type": "folder"}]}`
Update folder permissions	`{"action": "manage-permissions", "resources": [{"type": "folder"}]}`
Delete folder	`{"action": "delete", "resources": [{"type": "folder"}]}`
Create/update dashboard	`{"action": "create-update", "resources": [{"type": "dashboard"}]}`
Import dashboard	`{"action": "create", "resources": [{"type": "dashboard"}]}`
Update dashboard permissions	`{"action": "manage-permissions", "resources": [{"type": "dashboard"}]}`
Restore old dashboard version	`{"action": "restore", "resources": [{"type": "dashboard"}]}`
Delete dashboard	`{"action": "delete", "resources": [{"type": "dashboard"}]}`

Library elements management

Action	Distinguishing fields
Create library element	`{"action": "create", "resources": [{"type": "library-element"}]}`
Update library element	`{"action": "update", "resources": [{"type": "library-element"}]}`
Delete library element	`{"action": "delete", "resources": [{"type": "library-element"}]}`

Data sources management

Action	Distinguishing fields
Create datasource	`{"action": "create", "resources": [{"type": "datasource"}]}`
Update datasource	`{"action": "update", "resources": [{"type": "datasource"}]}`
Delete datasource	`{"action": "delete", "resources": [{"type": "datasource"}]}`
Enable permissions for datasource	`{"action": "enable-permissions", "resources": [{"type": "datasource"}]}`
Disable permissions for datasource	`{"action": "disable-permissions", "resources": [{"type": "datasource"}]}`
Grant datasource permission to role, team, or user	`{"action": "create", "resources": [{"type": "datasource"}, {"type": "dspermission"}]}`*
Remove datasource permission	`{"action": "delete", "resources": [{"type": "datasource"}, {"type": "dspermission"}]}`
Enable caching for datasource	`{"action": "enable-cache", "resources": [{"type": "datasource"}]}`
Disable caching for datasource	`{"action": "disable-cache", "resources": [{"type": "datasource"}]}`
Update datasource caching configuration	`{"action": "update", "resources": [{"type": "datasource"}]}`

* resources may also contain a third item with "type": set to "user" or "team".

Alerts and notification channels management

Action	Distinguishing fields
Save alert manager configuration	`{"action": "update", "requestUri": "/api/alertmanager/RECIPIENT/config/api/v1/alerts"}`
Reset alert manager configuration	`{"action": "delete", "requestUri": "/api/alertmanager/RECIPIENT/config/api/v1/alerts"}`
Create silence	`{"action": "create", "requestUri": "/api/alertmanager/RECIPIENT/api/v2/silences"}`
Delete silence	`{"action": "delete", "requestUri": "/api/alertmanager/RECIPIENT/api/v2/silences/SILENCE-ID"}`
Create alert	`{"action": "create", "requestUri": "/api/ruler/RECIPIENT/api/v2/alerts"}`
Create or update rule group	`{"action": "create-update", "requestUri": "/api/ruler/RECIPIENT/api/v1/rules/NAMESPACE"}`
Delete rule group	`{"action": "delete", "requestUri": "/api/ruler/RECIPIENT/api/v1/rules/NAMESPACE/GROUP-NAME"}`
Delete namespace	`{"action": "delete", "requestUri": "/api/ruler/RECIPIENT/api/v1/rules/NAMESPACE"}`
Test Grafana managed receivers	`{"action": "test", "requestUri": "/api/alertmanager/RECIPIENT/config/api/v1/receivers/test"}`
Create or update the NGalert configuration of the user’s organization	`{"action": "create-update", "requestUri": "/api/v1/ngalert/admin_config"}`
Delete the NGalert configuration of the user’s organization	`{"action": "delete", "requestUri": "/api/v1/ngalert/admin_config"}`

Where the following:

RECIPIENT is grafana for requests handled by Grafana or the data source UID for requests forwarded to a data source.
NAMESPACE is the string identifier for the rules namespace.
GROUP-NAME is the string identifier for the rules group.
SILENCE-ID is the ID of the affected silence.

The following legacy alerting actions are still supported:

Action	Distinguishing fields
Test alert rule	`{"action": "test", "resources": [{"type": "panel"}]}`
Pause alert	`{"action": "pause", "resources": [{"type": "alert"}]}`
Pause all alerts	`{"action": "pause-all"}`
Test alert notification channel	`{"action": "test", "resources": [{"type": "alert-notification"}]}`
Create alert notification channel	`{"action": "create", "resources": [{"type": "alert-notification"}]}`
Update alert notification channel	`{"action": "update", "resources": [{"type": "alert-notification"}]}`
Delete alert notification channel	`{"action": "delete", "resources": [{"type": "alert-notification"}]}`

Reporting

Action	Distinguishing fields
Create report	`{"action": "create", "resources": [{"type": "report"}, {"type": "dashboard"}]}`
Update report	`{"action": "update", "resources": [{"type": "report"}, {"type": "dashboard"}]}`
Delete report	`{"action": "delete", "resources": [{"type": "report"}]}`
Send report by email	`{"action": "email", "resources": [{"type": "report"}]}`
Update reporting settings	`{"action": "change-settings"}`

Annotations, playlists and snapshots management

Action	Distinguishing fields
Create annotation	`{"action": "create", "resources": [{"type": "annotation"}]}`
Create Graphite annotation	`{"action": "create-graphite", "resources": [{"type": "annotation"}]}`
Update annotation	`{"action": "update", "resources": [{"type": "annotation"}]}`
Patch annotation	`{"action": "patch", "resources": [{"type": "annotation"}]}`
Delete annotation	`{"action": "delete", "resources": [{"type": "annotation"}]}`
Delete all annotations from panel	`{"action": "mass-delete", "resources": [{"type": "dashboard"}, {"type": "panel"}]}`
Create playlist	`{"action": "create", "resources": [{"type": "playlist"}]}`
Update playlist	`{"action": "update", "resources": [{"type": "playlist"}]}`
Delete playlist	`{"action": "delete", "resources": [{"type": "playlist"}]}`
Create a snapshot	`{"action": "create", "resources": [{"type": "dashboard"}, {"type": "snapshot"}]}`
Delete a snapshot	`{"action": "delete", "resources": [{"type": "snapshot"}]}`
Delete a snapshot by delete key	`{"action": "delete", "resources": [{"type": "snapshot"}]}`

Provisioning

Action	Distinguishing fields
Reload provisioned dashboards	`{"action": "provisioning-dashboards"}`
Reload provisioned datasources	`{"action": "provisioning-datasources"}`
Reload provisioned plugins	`{"action": "provisioning-plugins"}`
Reload provisioned notifications	`{"action": "provisioning-notifications"}`
Reload provisioned alerts	`{"action": "provisioning-alerts"}`
Reload provisioned access control	`{"action": "provisioning-accesscontrol"}`

Plugins management

Action	Distinguishing fields
Install plugin	`{"action": "install"}`
Uninstall plugin	`{"action": "uninstall"}`

Miscellaneous

Action	Distinguishing fields
Set licensing token	`{"action": "create", "requestUri": "/api/licensing/token"}`
Save billing information	`{"action": "billing-information"}`

Generic actions

In addition to the actions listed above, any HTTP request (POST, PATCH, PUT, and DELETE) against the API is recorded with one of the following generic actions.

Furthermore, you can also record GET requests. See below how to configure it.

Action	Distinguishing fields
POST request	`{"action": "action"}`
PATCH request	`{"action": "partial-update"}`
PUT request	`{"action": "update"}`
DELETE request	`{"action": "delete"}`
GET request	`{"action": "retrieve"}`

Configuration

Note
The auditing feature is disabled by default.

Audit logs can be saved into files, sent to a Loki instance or sent to the Grafana default logger. By default, only the file exporter is enabled. You can choose which exporter to use in the configuration file.

Options are file, loki, and logger. Use spaces to separate multiple modes, such as file loki.

By default, when a user creates or updates a dashboard, its content will not appear in the logs as it can significantly increase the size of your logs. If this is important information for you and you can handle the amount of data generated, then you can enable this option in the configuration.

[auditing]
# Enable the auditing feature
enabled = false
# List of enabled loggers
loggers = file
# Keep dashboard content in the logs (request or response fields); this can significantly increase the size of your logs.
log_dashboard_content = false
# Keep requests and responses body; this can significantly increase the size of your logs.
verbose = false
# Write an audit log for every status code.
# By default it only logs the following ones: 2XX, 3XX, 401, 403 and 500.
log_all_status_codes = false
# Maximum response body (in bytes) to be audited; 500KiB by default.
# May help reducing the memory footprint caused by auditing.
max_response_size_bytes = 512000

Each exporter has its own configuration fields.

File exporter

Audit logs are saved into files. You can configure the folder to use to save these files. Logs are rotated when the file size is exceeded and at the start of a new day.

[auditing.logs.file]
# Path to logs folder
path = data/log
# Maximum log files to keep
max_files = 5
# Max size in megabytes per log file
max_file_size_mb = 256

Loki exporter

Audit logs are sent to a Loki service, through HTTP or gRPC.

Note
The HTTP option for the Loki exporter is available only in Grafana Enterprise version 7.4 and later.

[auditing.logs.loki]
# Set the communication protocol to use with Loki (can be grpc or http)
type = grpc
# Set the address for writing logs to Loki (format must be host:port)
url = localhost:9095
# Defaults to true. If true, it establishes a secure connection to Loki
tls = true
# Set the tenant ID for Loki communication, which is disabled by default.
# The tenant ID is required to interact with Loki running in multi-tenant mode.
tenant_id =

If you have multiple Grafana instances sending logs to the same Loki service or if you are using Loki for non-audit logs, audit logs come with additional labels to help identifying them:

host - OS hostname on which the Grafana instance is running.
grafana_instance - Application URL.
kind - auditing

Console exporter

Audit logs are sent to the Grafana default logger. The audit logs use the auditing.console logger and are logged on debug-level, learn how to enable debug logging in the log configuration section of the documentation. Accessing the audit logs in this way is not recommended for production use.

Export logs of usage insights

Fri, 13 Mar 2026 14:43:40 -0400

Export logs of usage insights

Note
Available in Grafana Enterprise version 7.4 and later, and Grafana Cloud Pro and Advanced.

By exporting usage logs to Loki, you can directly query them and create dashboards of the information that matters to you most, such as dashboard errors, most active organizations, or your top-10 most-used queries. This configuration is done for you in Grafana Cloud, with provisioned dashboards. Read about them in the Grafana Cloud documentation.

Usage insights logs

Usage insights logs are JSON objects that represent certain user activities, such as:

A user opens a dashboard.
A query is sent to a data source.

Scope

A log is created every time a user opens a dashboard or when a query is sent to a data source in the dashboard view. A query that is performed via Explore does not generate a log.

Format

Logs of usage insights contain the following fields, where the fields followed by * are always available, and the others depend on the logged event:

Field name	Type	Description
`eventName`*	string	Type of the event, which can be either `data-request` or `dashboard-view`.
`folderName`*	string	Name of the dashboard folder.
`dashboardName`*	string	Name of the dashboard where the event happened.
`dashboardId`*	number	ID of the dashboard where the event happened.
`datasourceName`	string	Name of the data source that was queried.
`datasourceType`	string	Type of the data source that was queried. For example, `prometheus`, `elasticsearch`, or `loki`.
`datasourceId`	number	ID of the data source that was queried.
`panelId`	number	ID of the panel of the query.
`panelName`	string	Name of the panel of the query.
`error`	string	Error returned by the query.
`duration`	number	Duration of the query.
`source`	string	Source of the query. For example, `dashboard` or `explore`.
`orgId`*	number	ID of the user’s organization.
`orgName`*	string	Name of the user’s organization.
`timestamp`*	string	The date and time that the request was made, in Coordinated Universal Time (UTC) in RFC3339 format.
`tokenId`*	number	ID of the user’s authentication token.
`username`*	string	Name of the Grafana user that made the request.
`userId`*	number	ID of the Grafana user that made the request.
`totalQueries`*	number	Number of queries executed for the data request.
`cachedQueries`*	number	Number of fetched queries that came from the cache.

Configuration

To export your logs, enable the usage insights feature and configure an export location in the configuration file:

[usage_insights.export]
# Enable the usage insights export feature
enabled = true
# Storage type
storage = loki

The options for storage type are loki and logger (added in Grafana Enterprise 8.2).

If the storage type is set to loki you’ll need to also configure Grafana to export to a Loki ingestion server. To do this, you’ll need Loki installed. Refer to Install Loki for instructions on how to install Loki.

[usage_insights.export.storage.loki]
# Set the communication protocol to use with Loki (can be grpc or http)
type = grpc
# Set the address for writing logs to Loki (format must be host:port)
url = localhost:9095
# Defaults to true. If true, it establishes a secure connection to Loki
tls = true
# Set the tenant ID for Loki communication, which is disabled by default.
# The tenant ID is required to interact with Loki running in multi-tenant mode.
tenant_id =

Using logger will print usage insights to your Grafana server log. There is no option for configuring the logger storage type.

Visualize Loki usage insights in Grafana

If you export logs into Loki, you can build Grafana dashboards to understand your Grafana instance usage.

Add Loki as a data source. Refer to Grafana fundamentals tutorial.
Import one of the following dashboards:
- Usage insights
- Usage insights datasource details
Play with usage insights to understand them:
- In Explore, you can use the query {datasource="gdev-loki",kind="usage_insights"} to retrieve all logs related to your gdev-loki data source.
- In a dashboard, you can build a table panel with the query topk(10, sum by (error) (count_over_time({kind="usage_insights", datasource="gdev-prometheus"} | json | error != "" [$__interval]))) to display the 10 most common errors your users see using the gdev-prometheus data source.
- In a dashboard, you can build a graph panel with the queries sum by(host) (count_over_time({kind="usage_insights"} | json | eventName="data-request" | error != "" [$__interval])) and sum by(host) (count_over_time({kind="usage_insights"} | json | eventName="data-request" | error = "" [$__interval])) to show the evolution of the data request count over time. Using by (host) allows you to have more information for each Grafana server you have if you have set up Grafana for high availability.

Configure Grafana secret scanning and notifications

Fri, 13 Mar 2026 14:43:40 -0400

Configure Grafana secret scanning and notifications

With Grafana, you can use the GitHub Secret Scanning service to determine if your service account tokens have been leaked on GitHub.

When GitHub Secret Scanning detects a Grafana secret, its hash is stored in Grafana Labs’ secret scanning service.

Grafana instances, whether on-premises or on the cloud, can use this service to verify if a token generated by the instance has been made public. This verification is done by comparing the token’s hash with the exposed token’s hash.

If the service detects a leaked token, it immediately revokes it, making it useless, and logs the event.

Note
If the revoke option is disabled, the service only sends a notification to the configured webhook URL and logs the event. The token is not automatically revoked.

You can also configure the service to send an outgoing webhook notification to a webhook URL.

The notification includes a JSON payload that contains the following data:

{
  "alert_uid": "c9ce50a1-d66b-45e4-9b5d-175766cfc026",
  "link_to_upstream_details": <URL to token leak>,
  "message": "Token of type grafana_service_account_token with name
sa-the-toucans has been publicly exposed in <URL to token leak>.
Grafana has revoked this token",
  "state": "alerting",
  "title": "SecretScan Alert: Grafana Token leaked"
}

Note
Secret scanning is disabled by default. Outgoing connections are made once you enable it.

Before you begin

Ensure all your API keys have been migrated to service accounts. For more information about service account migration, refer to Migrate API keys to Grafana service accounts.

Configure secret scanning

Open the Grafana configuration file.
In the [secretscan] section, update the following parameters:

[secretscan]
# Enable secretscan feature
enabled = true

# Whether to revoke the token if a leak is detected or just send a notification
revoke = true

Save the configuration file and restart Grafana.

Configure outgoing webhook notifications

Create an oncall integration of the type Webhook and set up alerts. To learn how to create a Grafana OnCall integration, refer to Inbound Webhook integrations for Grafana OnCall.
Copy the webhook URL of the new integration.
Open the Grafana configuration file.
In the [secretscan] section, update the following parameters, replacing the URL with the webhook URL you copied in step 2.

[secretscan]
# URL to send a webhook payload in oncall format
oncall_url = https://example.url/integrations/v1/webhook/3a359nib9eweAd9lAAAETVdOx/

Save the configuration file and restart Grafana.

Configure Team Sync

Fri, 13 Mar 2026 14:43:40 -0400

Configure Team Sync

Team sync lets you set up synchronization between your auth providers teams and teams in Grafana. This enables LDAP, OAuth, or SAML users who are members of certain teams or groups to automatically be added or removed as members of certain teams in Grafana.

Note: Available in Grafana Enterprise and Grafana Cloud Advanced.

Grafana keeps track of all synchronized users in teams, and you can see which users have been synchronized in the team members list, see LDAP label in screenshot. This mechanism allows Grafana to remove an existing synchronized user from a team when its group membership changes. This mechanism also enables you to manually add a user as member of a team, and it will not be removed when the user signs in. This gives you flexibility to combine LDAP group memberships and Grafana team memberships.

Currently the synchronization only happens when a user logs in, unless LDAP is used with the active background synchronization that was added in Grafana 6.3.

Supported providers

Synchronize a Grafana team with an external group

If you have already grouped some users into a team, then you can synchronize that team with an external group.

In Grafana, navigate to Administration > Teams.
Select a team.
Go to the External group sync tab, and click Add group.
Insert the value of the group you want to sync with. This becomes the Grafana GroupID. Examples:
- For LDAP, this is the LDAP distinguished name (DN) of LDAP group you want to synchronize with the team.
- For Auth Proxy, this is the value we receive as part of the custom Groups header.
Click Add group to save.

Group matching is case insensitive.

LDAP specific: wildcard matching

When using LDAP, you can use a wildcard (*) in the common name attribute (CN) to match any group in the corresponding Organizational Unit (OU).

Ex: cn=*,ou=groups,dc=grafana,dc=org can be matched by cn=users,ou=groups,dc=grafana,dc=org

Configure request security

Fri, 13 Mar 2026 14:43:40 -0400

Configure request security

Request security allows you to limit requests from the Grafana server by targeting requests generated by users, such as data source metric queries and alert notifications.

This can be used to limit access to internal systems that the server Grafana runs on can access but that users of Grafana should not be able to access. This feature does not affect traffic from the Grafana users browser.

Note
Available in Grafana Enterprise version 7.4 and later, and Grafana Cloud Pro and Advanced.

Note
Although request security works with backend plugins, you can create a backend plugin that bypasses this security.

IP and hostname blocking

You can limit requests based on a hostname, an IP address, or both.

Deny list

Grafana blocks any request to a hostname or IP address on the deny list.

Allow list

If there is at least one entry on the list, then any request to a hostname or IP address not on the list is denied.

For example:

[security.egress]
# A list of hostnames or IP addresses separated by spaces for which requests are blocked.
host_deny_list = supersecret.internal 192.168.1.10
# a list of hostnames or IP addresses separated by spaces for which requests will be allowed, all other requests will be blocked
host_allow_list = prometheus.internal

Drop headers and cookies

You can set a list of cookies or headers that are to be dropped from outgoing requests.

Example:

[security.egress]
# a list of headers that will be stripped from outgoing datasource and alerting requests
header_drop_list = user
# a list of cookies that will be stripped from outgoing datasource requests (case sensitive)
cookie_drop_list = session_id

Configure security hardening

Fri, 13 Mar 2026 14:43:40 -0400

Configure security hardening

Security hardening enables you to apply additional security, which can help stop certain vulnerabilities from being exploited by a malicious attacker.

Note
These settings are available in the grafana.ini configuration file. To apply changes to the configuration file, restart the Grafana server.

Additional security for cookies

If Grafana uses HTTPS, you can further secure the cookie that the system uses to authenticate access to the web UI. By applying additional security to the cookie, you might mitigate certain attacks that result from an attacker obtaining the cookie value.

Note
Grafana must use HTTPS for the following configurations to work properly.

Add a secure attribute to cookies

To provide mitigation against some MITM attacks, add the Secure attribute to the cookie that is used to authenticate users. This attribute forces users only to send the cookie over a valid HTTPS secure connection.

Example:

# Set to true if you host Grafana behind HTTPS. The default value is false.
cookie_secure = true

Add a SameSite attribute to cookies

To mitigate almost all CSRF-attacks, set the cookie_samesite option to strict. This setting prevents clients from sending the cookie in requests that are made cross-site, but only from the site that creates the cookie.

Example:

# set cookie SameSite attribute. defaults to `lax`. can be set to "lax", "strict", "none" and "disabled"
cookie_samesite = strict

Note
By setting the SameSite attribute to “strict,” only the user clicks within a Grafana instance work. The default option, “lax,” does not produce this behavior.

You can further secure the cookie authentication by adding a Cookie Prefix. Cookies without a special prefix can be overwritten in a man-in-the-middle attack, even if the site uses HTTPS. A cookie prefix forces clients only to accept the cookie if certain criteria are met. Add a prefix to the current cookie name with either __Secure- or __Host- where the latter provides additional protection by only allowing the cookie to be created from the host that sent the Set-Cookie header.

Example:

# Login cookie name
login_cookie_name = __Host-grafana_session

Security headers

Grafana includes a few additional headers that you can configure to help mitigate against certain attacks, such as XSS.

Add a Content Security Policy

A content security policy (CSP) is an HTTP response header that controls how the web browser handles content, such as allowing inline scripts to execute or loading images from certain domains. The default CSP template is already configured to provide sufficient protection against some attacks. This makes it more difficult for attackers to execute arbitrary JavaScript if such a vulnerability is present.

Example:

# Enable adding the Content-Security-Policy header to your requests.
# CSP enables you to control the resources the user agent can load and helps prevent XSS attacks.
content_security_policy = true

# Set the Content Security Policy template that is used when the Content-Security-Policy header is added to your requests.
# $NONCE in the template includes a random nonce.
# $ROOT_PATH is server.root_url without the protocol.
content_security_policy_template = """script-src 'self' 'unsafe-eval' 'unsafe-inline' 'strict-dynamic' $NONCE;object-src 'none';font-src 'self';style-src 'self' 'unsafe-inline' blob:;img-src * data:;base-uri 'self';connect-src 'self' grafana.com ws://$ROOT_PATH wss://$ROOT_PATH;manifest-src 'self';media-src 'none';form-action 'self';"""

Enable trusted types

Currently in development. Trusted types is an experimental Javascript API with limited browser support.

Trusted types reduce the risk of DOM XSS by enforcing developers to sanitize strings that are used in injection sinks, such as setting innerHTML on an element. Furthermore, when enabling trusted types, these injection sinks need to go through a policy that will sanitize, or leave the string intact and return it as “safe”. This provides some protection from client side injection vulnerabilities in third party libraries, such as jQuery, Angular and even third party plugins.

To enable trusted types in enforce mode, where injection sinks are automatically sanitized:

Enable content_security_policy in the configuration.
Add require-trusted-types-for 'script' to the content_security_policy_template in the configuration.

To enable trusted types in report mode, where inputs that have not been sanitized with trusted types will be logged to the console:

Enable content_security_policy_report_only in the configuration.
Add require-trusted-types-for 'script' to the content_security_policy_report_only_template in the configuration.

As this is a feature currently in development, things may break. If they do, or if you have any other feedback, feel free to leave a comment.

Additional security hardening

The Grafana server has several built-in security features that you can opt-in to enhance security. This section describes additional techniques you can use to harden security.

Hide the version number

If set to true, the Grafana server hides the running version number for unauthenticated users. Version numbers might reveal if you are running an outdated and vulnerable version of Grafana.

Example:

# mask the Grafana version number for unauthenticated users
hide_version = true

Enforce domain verification

If set to true, the Grafana server redirects requests that have a Host-header value that is mismatched to the actual domain. This might help to mitigate some DNS rebinding attacks.

Example:

# Redirect to correct domain if host header does not match domain
# Prevents DNS rebinding attacks
enforce_domain = true

Configure security on Grafana Labs

Plan your IAM integration strategy

Plan your IAM integration strategy

Benefits of integrating with an IAM provider

Internal vs external users

Ways to organize users

Users in Grafana teams

Users in Grafana organizations

Choosing between teams and organizations

Access to external systems

Service accounts

Service account tokens

API keys

How to work with roles?

What are roles?

What are permissions?

Role-based access control

User synchronization between Grafana and identity providers

Team sync

Role Sync

Organization sync

Configure authentication

Configure authentication

Configuring multiple identity providers

Grafana Auth

Login and short-lived tokens

Remote logout

Settings

Anonymous authentication

Basic authentication

Disable login form

Enable email lookup

Automatic OAuth login

Avoid automatic OAuth login

Hide sign-out menu

URL redirect after signing out

Protected roles

Configure database encryption

Configure database encryption

Envelope encryption

Implicit breaking change

Operational work

Re-encrypt secrets

Roll back secrets

Re-encrypt data keys

Rotate data keys

Encrypting your database with a key from a key management service (KMS)

Changing your encryption mode to AES-GCM

Audit a Grafana instance

Audit a Grafana instance

Audit logs

Format

Recorded actions

Sessions

Service accounts

Access control

User management

Team and organization management

Folder and dashboard management

Library elements management

Data sources management

Alerts and notification channels management

Reporting

Annotations, playlists and snapshots management

Provisioning

Plugins management

Miscellaneous

Generic actions

Configuration

File exporter

Loki exporter

Console exporter

Export logs of usage insights

Export logs of usage insights

Usage insights logs

Scope

Format

Configuration

Visualize Loki usage insights in Grafana

Configure Grafana secret scanning and notifications