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

Configure LBAC for data sources for Loki

Tue, 18 Aug 2026 10:15:08 +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

Tue, 18 Aug 2026 21:15:34 +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

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

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

Tue, 18 Aug 2026 10:15:08 +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" }.

Configure team LBAC for data sources for Tempo

Tue, 18 Aug 2026 10:15:08 +0000

Configure team label-based access control for Tempo or Cloud Traces

Note
Label-based access control for traces is currently in public preview. Grafana Labs offers limited support, and breaking changes might occur prior to the feature being made generally available.

Team label-based access control (LBAC) for Cloud Traces or Tempo lets you restrict which spans teams can access by defining rules using trace attributes. LBAC provides fine-grained, team-based access control within a single tenant and mirrors the experience used for logs and metrics LBAC in Grafana Cloud.

Note
Unlike logs and metrics, which also support data source-level LBAC through cloud access policies, traces LBAC is currently available only at the team level.

Grafana uses the term LBAC as an umbrella term for label-based access control for all data sources. Traces use attributes, not labels, for access control, but the Grafana UI surfaces this functionality as LBAC for consistency.

This feature only applies to Grafana Cloud Traces, specifically, the Cloud-provisioned tracing data source.

How LBAC works

When a user queries tracing data source, Grafana evaluates the user’s team memberships and the LBAC rules assigned to those teams. These rules are added to the request so the Cloud Traces data source returns only permitted spans or attributes.

LBAC rules use attribute selectors, such as:

{ resource.service.name="checkout", resource.env="prod" }

Multiple conditions in the same rule use AND (,), while multiple rules across teams use OR.

Before you begin

Be sure that you have the permission setup to create a Tempo or Cloud Traces tenant in Grafana Cloud.
Be sure that you have administrator permissions for Grafana.
Be sure that you have a team setup in Grafana.

Known limitations

LBAC for traces is available only at the team level. Data source-level LBAC rules (configured through cloud access policies) aren’t currently supported for traces. This differs from logs and metrics LBAC, which supports both team-level and data source-level rules.
Autocomplete in search is still under development.
LBAC is restricted to only contain resource scope attributes.
There is a slight performance degradation for users with multiple rules.

Configure team LBAC for traces

Follow this workflow when adding a new data source. The data source must be hosted by Grafana and not self-managed.

Start your Grafana Cloud instance.
Access Tempo or Cloud Traces data sources details for your stack.
Copy Tempo or Cloud Traces details and create a Cloud Access Policy.
- Copy the details of your Tempo or Cloud Traces setup.
In Grafana Cloud, navigate to Administration > Users and access > Cloud Access Policies.
- Create an access policy for the Tempo or Cloud Traces data source.
- Ensure the access policy includes traces:read permissions.
- Ensure the access policy doesn’t include labels rules. Data source-level LBAC isn’t supported for traces, so any labels rules in the access policy are ignored.
In Grafana, select Tempo or Cloud Traces or create new data source.
Navigate back to the Tempo or Cloud Traces data source.
- Set up the Tempo or Cloud Traces data source using basic authentication. Use the userID/tenantID as the username. Use the token from your access policy as the password.
- Select Save and connect.
Go to the Permissions tab of the newly created Tempo or Cloud Traces data source. Here, you find the LBAC for data sources rules section.
Choose a team from the Team dropdown.
Enter attribute selectors such as:
```
{ resource.service.name="checkout", resource.env="prod" }
```
Refer to the Examples section below for more examples.
Select Save.

Examples of LBAC rules

An LBAC rule is a logql query that filters logs or metrics based on labels. LBAC rules for traces also use some TraceQL syntax for attribute selection. Each rule operates independently as its own filter, separate from other rules within a team.

LBAC rules guidelines:

Use only resource scope attributes, for example { resource.env="prod" }.
Only string values are supported.
Use double quotes for string values, for example: { resource.env="prod" }.
You can use regular expressions matching with =~ operator, for example: { resource.team =~ "team-a|team-b" }.
You can have up to two conditions in the same rule using a comma (,) as an AND operator, for example: { resource.env="prod", resource.team="frontend" }.

Refer to Create LBAC for data sources rules for a supported data source for more information.

Single rule

Limit users to only see spans from the payments API.

{ resource.service.name="payments-api" }

This example matches spans with team A or team B. This single example is faster than using multiple rules with the same label.

{ resource.team =~ "team-a|team-b" }

Multiple rules

Two rules combined to give user access to spans from prod environment or the billing team.

{ resource.env="prod" }
{ resource.team="billing" }

This example gives users access to spans from the frontend team in the prod environment or the checkout team but doesn’t enforce additional conditions. The comma (,) acts as an AND operator within the same rule.

{ resource.env="prod", resource.team="frontend" }
{ resource.team="checkout" }

User on multiple teams

Users on multiple teams receive access based on all combined LBAC rules assigned to each team.

Team A → { resource.cluster="us-east-1" } Team B → { resource.service.name="frontend" }

How LBAC affects returned data

Cloud Traces supports three redaction modes that control how unauthorized spans are handled in trace by ID search responses. The active mode is configured per tenant. To change the mode for your organization, contact Grafana Support.

Attributes mode (default)

Non-matching spans are included in the response but have their attributes and intrinsics redacted. Only the following minimal fields remain visible on redacted spans:

traceId, spanId, parentId
name, kind
timestamps
status

You can extend the set of always-visible fields by configuring allowed_attributes, which sets a list of scoped attributes and intrinsics that are never redacted, For example, you can set span:name, resource.service.name, event:name, or scope.version so they are never redacted, even from non-matching spans. Contact Grafana Support to configure allowed_attributes for your organization.

Spans mode

Non-matching spans are removed from the response entirely. This can result in broken traces where a returned span has no matching parent, creating gaps in the span tree.

Error mode

If any span in a requested trace does not match the LBAC policy, the entire request returns a 404 error. This is the strictest mode and is suited for environments where partial trace visibility is not acceptable.

For Search, metrics, and autocomplete endpoints, only spans matching the LBAC rules appear regardless of the configured redaction mode.

Manage LBAC rules

To edit an existing LBAC rule, follow these steps:

Open your stack and select your Tempo or Cloud Traces data source.
Select Permissions.
Scroll to Data access.
Select the rule you want to edit and click the Pencil (Edit) icon.
Modify Attribute filters.
Select Save.

To delete an existing LBAC rule, follow these steps:

Open your stack and select your Tempo or Cloud Traces data source.

Select Permissions.
Scroll to Data access.
Select the rule you want to edit.
Select the X (Delete) icon.
Confirm deletion.