Label Based Access Control (LBAC) for data sources on Grafana Labs

Configure LBAC for data sources for Loki

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

Configure LBAC for data sources for Loki data source on Grafana Cloud

LBAC for data sources is available on Grafana Cloud using a new Loki data source with basic authentication configured. A new data source can be created as described in LBAC Configuration for New Loki Data Source.

Before you begin

Be sure that you have the permission setup to create a Loki tenant in Grafana Cloud
Be sure that you have admin data source permissions for Grafana.

Permissions

We recommend that you remove all permissions for roles and teams that are not required to access the data source. This will help to ensure that only the required teams have access to the data source. The recommended permissions are Admin permission and only add the teams Query permissions that you want to add LBAC for data sources rules for.

Task 1: LBAC Configuration for New Loki Data Source

Access Loki data sources details for your stack through grafana.com
Copy Loki details and create a CAP
- Copy the details of your Loki setup.
- Create a Cloud Access Policy (CAP) for the Loki data source in grafana.com.
- Ensure the CAP includes logs:read permissions.
- Ensure the CAP does not include labels rules.
Create a new Loki data source
- In Grafana, proceed to add a new data source and select Loki as the type.
Navigate back to the Loki data source
- Set up the Loki data source using basic authentication. Use the userID as the username. Use the generated CAP token as the password.
- Save and connect.
Navigate to data source permissions
- Go to the permissions tab of the newly created Loki data source. Here, you’ll find the LBAC for data sources rules section.

For more information on how to setup LBAC for data sources rules for a Loki data source, refer to Create LBAC for data sources rules for the Loki data source.

Configure LBAC for data sources for Prometheus

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

Configure LBAC for data sources for Prometheus data source

Grafana Cloud

LBAC for data sources is available on Grafana Cloud using a new Prometheus data source with basic authentication configured. A new data source can be created as described in LBAC Configuration for New Prometheus Data Source.

Before you begin

To be able to use LBAC for Prometheus data sources, you need to enable the feature toggle teamHttpHeadersMimir on your Grafana instance. Go to the feature toggles page in setting to enable the feature.

Be sure that you have the permission setup to create a Prometheus tenant in Grafana Cloud
Be sure that you have admin data source permissions for Grafana.

Grafana Cloud

LBAC for data sources is available in private preview on Grafana Cloud for Prometheus created with basic authentication. Prometheus data sources for LBAC for data sources can only be created, provisioning is currently not available.

You cannot configure LBAC rules for Grafana-provisioned data sources from the UI. We recommend that you replicate the setting of the provisioned data source in a new data source as described in LBAC Configuration for New Prometheus Data Source and then add the LBAC configuration to the new data source.

Permissions

Task 1: LBAC Configuration for new Prometheus data source

Access Prometheus data sources details for your stack through grafana.com
Copy Prometheus details and create a CAP
- Copy the details of your Prometheus setup.
- Create a Cloud Access Policy (CAP) for the Prometheus data source in grafana.com.
- Ensure the CAP includes metrics:read permissions.
- Ensure the CAP does not include labels rules.
Create a new Prometheus data source
- In Grafana, proceed to add a new data source and select Prometheus as the type.
Navigate back to the Prometheus data source
- Set up the Prometheus data source using basic authentication. Use the userID as the username. Use the generated CAP token as the password.
- Save and connect.
Navigate to data source permissions
- Go to the permissions tab of the newly created Prometheus data source. Here, you’ll find the LBAC for data sources rules section.

For more information on how to setup LBAC for data sources rules for a Prometheus data source, refer to Create LBAC for data sources rules for the Prometheus data source.

Grafana Enterprise

LBAC for data sources is available in Grafana Enterprise for Prometheus connected to GEM created with basic authentication.

You cannot configure LBAC rules for Grafana-provisioned data sources from the UI. Alternatively, you can replicate the setting of the provisioned data source in a new data source as described in LBAC Configuration for new Prometheus data source and then add the LBAC configuration to the new data source.

Before you begin

To be able to use LBAC for Prometheus data sources, you need to enable the feature toggle teamHttpHeadersMimir on your Grafana instance. Contact support to enable the feature toggle for you.

Be sure that you have the permission setup to create a cluster in your Grafana
Be sure that you have admin plugins permissions for Grafana.
Be sure that you have admin data source permissions for Grafana.

Permissions

Task 0: Setup Grafana Enterprise Metrics tenant and access policies

Access the plugins page and install Grafana Enterprise Metrics plugins
Connect your plugin and use app as the cluster
Access the app Grafana Enterprise Metrics and configure a tenant
Store the uid of the tenant to be used as the username for the basic authentication
Access the policies page inside of the app and create a AP
- Create a Access Policy (CAP) for the Prometheus data source.
- Ensure the CAP includes metrics:read permissions.
- Ensure the CAP does not include labels rules.
- Store the token to be used as password for authentication.

Task 1: LBAC Configuration for new Prometheus data source

Create a new Prometheus data source
- In Grafana, proceed to add a new data source and select Prometheus as the type.
Navigate back to the Prometheus data source
- Set up the Prometheus data source using basic authentication. Use the uid as the username. Use the generated token as the password.
- Save and connect.
Navigate to data source permissions
- Go to the permissions tab of the newly created Prometheus data source. Here, you’ll find the LBAC for data sources rules section.

For more information on how to setup LBAC for data sources rules for a Prometheus data source, refer to Create LBAC for data sources rules for the Prometheus data source.

Create LBAC for data sources rules for a supported data source

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

Create LBAC for data source rule

LBAC for data sources is available for LBAC-supported data sources created with basic authentication. As of today, managed/provisioned data source can NOT be configured with LBAC rules.

Before you begin

Be sure that you have the permission setup to create a Loki tenant in Grafana Cloud.
Be sure that you have admin data source permissions for Grafana.
Be sure that you have a team setup in Grafana.

Create a LBAC for data sources rule for a team

Navigate to your data source
Navigate to the permissions tab
- Here, you’ll find the LBAC for data sources rules section.
Add a LBAC for data sources Rule
- Add a new rule for the team in the LBAC for data sources rules section.
Define a label selector for the rule
- Add a label selector to the rule. Refer to documentation for guidance on the types of log selections you can specify.

LBAC rule

An LBAC rule is a logql query that filters logs or metrics based on labels. Each rule operates independently as its own filter, separate from other rules within a team.

For example:

For logs: {namespace="dev", cluster="us-west-0"} filters log lines matching both namespace="dev" and cluster="us-west-0".
For metrics: {job="api-server", region="europe"} filters metric data points matching job="api-server" and region="europe".

One rule {namespace="dev", cluster="us-west-0"} created with multiple namespaces will be seen as namespace="dev" AND cluster="us-west-0". Two rules {namespace="dev"}, {cluster="us-west-0"} created for a team will be seen as namespace="dev" OR cluster="us-west-0".

Best practices

We recommend you only add query permissions for teams that should use the data source and only Admin have Admin permissions.

We recommend for a first setup, setting up as few rules as possible for each team and make them additive for simplicity.

To validate the rules, we recommend testing the rules in the Explore view. This will allow you to see the metrics or logs that would be returned for the rule.

Tasks

Task 1: One rule setup for each team

One common use case for creating an LBAC policy is to grant access to logs or metrics with a specific label. For example, you can create a label policy that includes all log lines or metrics with the label namespace.

We have two teams, Team A and Team B with Query permissions. Data source access is set up with Admin roles to have Admin permission only.

Team A has a rule namespace="dev".
Team B has a rule namespace="prod".

A user that is part of Team A will have access to logs or metrics matching namespace="dev". A user in both Team A and Team B will have access to data matching namespace="dev" OR namespace="prod".

Task 2: Set up a rule to exclude a label for a team

One common use case for creating an LBAC policy is to exclude logs or metrics that have a specific label. For example, you can create a label policy that excludes all log lines with the label secret=true by adding a selector with secret!="true" when you create an access policy:

We have one team, Team A Query permissions. Data source access is setup with Admin roles to have Admin permission only.

Team A has a rule secret!="true".

A user that is part of Team A will NOT have access to logs or metrics that match secret!="true".

Task 3: Set up multiple rules for a team

We have two teams, Team A and Team B with Query permissions. Data Source access is setup with Admin roles having Admin permission.

Team A has rule cluster="us-west-0", namespace=~"dev|prod" configured.
Team B has rule cluster="us-west-0", namespace="staging" configured.

A user that is only part of Team A will have access to logs that match cluster="us-west-0" AND (namespace="dev" OR namespace="prod").

A user that is only part of Team B will have access to logs that match cluster="us-west-0" AND namespace="staging".

A user in Team A has access to logs in cluster us-west-0 with namespaces dev and prod. A user in Team B has access to to everything in cluster us-west-0, except namespace prod. So basically, user who is member of both team A and team B has access to everything in cluster us-west-0.

A user that is not part of any Team with Editor/Viewer role will not have access to query any logs.

Important

A Admin user that is part of a Team with will only have access to that teams logs

A Admin user that is not part of any Team with Admin role will have access to all logs

Task 4: Rules that overlap

We have two teams, Team A and Team B.

Team A has a rule namespace="dev".
Team B has a rule namespace!="dev".

A user in Team A will have access to logs that match namespace="dev".

A user in Team B will have access to logs that match namespace!="dev".

NOTE: A user that is part of Team A and Team B will have access to all logs that match namespace="dev" OR namespace!="dev".

Task 5: Single rule setup for a team

We have two teams, Team A and Team B. Data Source access is setup with Editor, Viewer roles to have Query permission.

Team A has a rule namespace="dev" configured.
Team B does not have a rule configured for it.

A user that is part of Team A will have access to logs that match namespace="dev".

A user that is part of Team A and part of Team B will have access to logs that match namespace="dev".

A user that is not part of Team A and part of Team B, that is Editor or Viewer will have access to all logs (due to the query permission for the user).

Task 6: User A is Admin and part of Team B

We have team B, user A is part of Team B and has an Admin basic role.

Team B has no roles assigned
Team B has Query permissions to data source
Team B has a rule { project_id="project-dev" }

User A may only access logs or metrics for a data source that match { project_id="project-dev" }.