Label-based access control (LBAC) for data sources on Grafana Labs

Create LBAC for data sources rules

Wed, 07 Oct 2026 20:20:36 +0000

Create LBAC for data sources rules

LBAC for data sources works with supported data sources that use basic authentication. You can’t add LBAC rules to a file-provisioned data source, and provisioned data sources are read-only in the UI. Create the data source first, then add its LBAC rules on the Permissions tab or provision them with the Grafana Terraform provider.

Before you begin

Before you start, ensure you have:

Tenant permissions: Permission to create the tenant for your data source, such as a Loki tenant, in Grafana Cloud or in Grafana Enterprise Metrics or Grafana Enterprise Logs.
Data source permissions: Admin permission on the data source in Grafana.
A team: At least one team set up in Grafana.

Create an LBAC for data sources rule for a team

To add an LBAC rule to a team:

Navigate to your data source.
Select the Permissions tab. The LBAC for data sources rules section appears on this tab.
In the LBAC for data sources rules section, add a new rule for the team.
Define a label selector for the rule. For the selector syntax, refer to LBAC rules. For data source-specific guidance, refer to the configuration guides in Next steps.

LBAC rules

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:

Logs: {namespace="dev", cluster="us-west-0"} returns log lines that match both namespace="dev" and cluster="us-west-0".
Metrics: {job="api-server", region="europe"} returns metric data points that match both job="api-server" and region="europe".

Within a single rule, comma-separated selectors combine with AND. For example, the rule {namespace="dev", cluster="us-west-0"} matches data where namespace="dev" AND cluster="us-west-0".

Across a team, multiple rules combine with OR. For example, the two rules {namespace="dev"} and {cluster="us-west-0"} match data where namespace="dev" OR cluster="us-west-0".

Note
An Admin user who’s a member of one or more teams with LBAC rules can access only the logs or metrics allowed by those teams’ rules. An Admin user who isn’t a member of any team with LBAC rules can access all logs or metrics.

Traces rules

For Tempo and Cloud Traces, rules use attribute selectors rather than LogQL labels. This functionality is in public preview, and traces LBAC is available only at the team level. Use resource-scope attributes, for example:

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

The same logic applies as for logs and metrics: comma-separated conditions in one rule combine with AND, and multiple rules across a team combine with OR. For more information, refer to Configure team LBAC for Tempo or Cloud Traces.

Best practices

Follow these recommendations when you set up rules:

Grant Query permission only to teams that should use the data source, and grant Admin permission only to administrators.
Give every team that should be restricted its own rule. A team that has Query permission but no rule can query all logs or metrics.
Remove label selectors from the Cloud Access Policy for the data source. Cloud Access Policy rules override LBAC for data sources rules.
For a first setup, create as few rules as possible for each team and prefer rules that grant access over rules that exclude data, because access is the union of all rules.
Use a dedicated data source for LBAC, and keep a separate data source without LBAC for full access, so the separation is clear.
Manage rules as code with the Grafana Terraform provider for repeatable, reviewable setups.
To validate rules, test them in Explore. Explore shows the logs or metrics that a rule returns.

Examples

The following examples show how different rule and team configurations affect access. Unless stated otherwise, each team has Query permission on the data source and administrators have Admin permission only.

One rule for each team

A common use case is to grant a team access to data that has a specific label. In this example, Team A and Team B each have one rule:

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

A user in Team A can access logs or metrics that match namespace="dev". A user in both Team A and Team B can access data that matches namespace="dev" OR namespace="prod".

Multiple rules for one team

A team can have more than one rule, and its members can access data that matches any of them. In this example, Team A has two rules:

Rule 1: namespace="dev"
Rule 2: namespace="prod"

A user in Team A can access logs or metrics that match namespace="dev" OR namespace="prod".

Exclude a label for a team

You can exclude data that has a specific label. For example, to exclude all log lines labeled secret="true", add the selector secret!="true". In this example, Team A has one rule:

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

A user in Team A can access logs or metrics that match secret!="true", which is all data except data labeled secret="true".

Rules with multiple conditions

A single rule can combine multiple conditions with AND. In this example, Team A and Team B each have one rule:

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

The =~ operator matches a regular expression, so namespace=~"dev|prod" matches either dev or prod.

A user in only Team A can access logs or metrics that match cluster="us-west-0" AND (namespace="dev" OR namespace="prod").

A user in only Team B can access logs or metrics that match cluster="us-west-0" AND namespace="staging".

A user in both Team A and Team B can access logs or metrics that match cluster="us-west-0" AND (namespace="dev", namespace="prod", or namespace="staging"), because rules across teams combine with OR.

A user with an Editor or Viewer role who isn’t a member of any team can’t query logs or metrics, because in this setup only teams have Query permission on the data source.

Rules that overlap

Two teams can have rules that overlap. In this example:

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

A user in Team A can access logs or metrics that match namespace="dev".

A user in Team B can access logs or metrics that match namespace!="dev".

Note
A user in both Team A and Team B can access all data, because the rules combine as namespace="dev" OR namespace!="dev".

Team without a rule

When a team has no LBAC rule, its members can access all logs or metrics, subject to their data source permission. In this example, the Editor and Viewer roles have Query permission:

Team A has the rule namespace="dev".
Team B has no rule configured.

A user in only Team A can access logs or metrics that match namespace="dev".

A user in both Team A and Team B can access logs or metrics that match namespace="dev".

A user in only Team B with an Editor or Viewer role can access all logs or metrics, because Team B has no rule and the user has Query permission.

Administrator on a team with a rule

An administrator’s basic role doesn’t bypass LBAC rules when the administrator is a member of a team that has rules. In this example, User A has an Admin basic role and is a member of Team B:

Team B has no roles assigned.
Team B has Query permission on the data source.
Team B has the rule { project_id="project-dev" }.

User A can access only logs or metrics that match { project_id="project-dev" }.

Next steps

Set up LBAC for data sources for your data source:

Configure LBAC for a Loki data source

Tue, 29 Sep 2026 22:18:37 +0000

Configure LBAC for a Loki data source

This document explains how to configure Label-Based Access Control (LBAC) for data sources for a Loki data source. LBAC for data sources filters the logs that a team can query based on labels. You can configure it on both Grafana Cloud and Grafana Enterprise.

Grafana Cloud

LBAC for data sources is generally available on Grafana Cloud for Loki data sources created with basic authentication. You create a new data source as described in Configure a new Loki data source. Provisioning is currently not available.

You can’t configure LBAC rules for Grafana-provisioned data sources from the UI. We recommend that you replicate the settings of the provisioned data source in a new data source, and then add the LBAC configuration to the new data source.

Before you begin

Before you configure LBAC for data sources, ensure you have the following:

Permission to create a Loki tenant in Grafana Cloud.
Admin data source permissions for Grafana.

Grafana recommends that you remove all permissions for roles and teams that don’t require access to the data source. This ensures that only the required teams access the data source. The recommended permissions are Admin permission for administrators, and Query permission only for the teams that you want to add LBAC for data sources rules for.

Configure a new Loki data source on Grafana Cloud

Access Loki data source details for your stack in Grafana Cloud.
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 Cloud.
- Ensure the CAP includes logs:read permissions.
- Ensure the CAP doesn’t include labels rules.
Create a new Loki data source.
- In Grafana, 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.
- Select Save & test.
Navigate to data source permissions.
- Go to the Permissions tab of the newly created Loki data source. Here, you find the LBAC for data sources rules section.

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

Grafana Enterprise

LBAC for data sources is available in Grafana Enterprise for Loki connected to Grafana Enterprise Logs (GEL), created with basic authentication.

You can’t configure LBAC rules for Grafana-provisioned data sources from the UI. Alternatively, you can replicate the settings of the provisioned data source in a new data source, and then add the LBAC configuration to the new data source.

Before you begin

Before you configure LBAC for data sources, ensure you have the following:

Permission to create a cluster in your Grafana.
Admin plugins permissions for Grafana.
Admin data source permissions for Grafana.

Set up a Grafana Enterprise Logs tenant and access policies

Access the plugins page and install the Grafana Enterprise Logs plugin.
Connect your plugin and use the app as the cluster.
Access the Grafana Enterprise Logs app and configure a tenant.
Store the uid of the tenant to use as the username for basic authentication.
Access the policies page inside the app and create an access policy.
- Create an access policy for the Loki data source.
- Ensure the access policy includes logs:read permissions.
- Ensure the access policy doesn’t include labels rules.
- Store the token to use as the password for authentication.

Configure a new Loki data source on Grafana Enterprise

Create a new Loki data source.
- In Grafana, 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 uid as the username. Use the generated token as the password.
- Select Save & test.
Navigate to data source permissions.
- Go to the Permissions tab of the newly created Loki data source. Here, you find the LBAC for data sources rules section.

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

Examples of LBAC rules

An LBAC rule is a logql query that filters logs based on labels. Each rule operates independently as its own filter, separate from other rules within a team. The following examples show common patterns. For more detail, refer to Create LBAC for data sources rules for the Loki data source.

Single rule

Multiple label selectors in a single rule are combined with AND. The following rule grants access to log lines that match both namespace="dev" and cluster="us-west-0":

{namespace="dev", cluster="us-west-0"}

Multiple rules

Multiple rules assigned to the same team are combined with OR. The following two rules grant access to log lines that match namespace="dev" or cluster="us-west-0":

{namespace="dev"}
{cluster="us-west-0"}

Match multiple values with a regular expression

Use the =~ operator to match a label against a regular expression. The following rule grants access to log lines in the dev or prod namespace:

{namespace=~"dev|prod"}

Exclude a label value

Use the != operator to exclude log lines that carry a specific label value. The following rule grants access to all log lines except those labeled secret="true":

{secret!="true"}

User on multiple teams

Users on multiple teams receive access based on all the combined rules assigned to each team, combined with OR. For example, if Team A has {namespace="dev"} and Team B has {namespace="prod"}, a user on both teams can access log lines that match namespace="dev" or namespace="prod".

LBAC for data sources overview explains how LBAC works, which data sources are supported, and current limitations.
Create LBAC for data sources rules for a supported data source explains how to define and manage rules.

Configure LBAC for a Prometheus data source

Wed, 07 Oct 2026 21:17:40 +0000

Configure LBAC for a Prometheus data source

This document explains how to configure Label-Based Access Control (LBAC) for data sources for a Prometheus data source. LBAC for data sources filters the metrics that a team can query based on labels. You can configure it on both Grafana Cloud and Grafana Enterprise.

Grafana Cloud

LBAC for data sources is generally available on Grafana Cloud for Prometheus data sources created with basic authentication. You create a new data source as described in Configure a new Prometheus data source. Provisioning is currently not available.

Before you begin

Before you configure LBAC for data sources, ensure you have the following:

Permission to create a Prometheus tenant in Grafana Cloud.
Admin data source permissions for Grafana.

Configure a new Prometheus data source on Grafana Cloud

Access Prometheus data source details for your stack in Grafana Cloud.
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 Cloud.
- Ensure the CAP includes metrics:read permissions.
- Ensure the CAP doesn’t include labels rules.
Create a new Prometheus data source.
- In Grafana, 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.
- Select Save & test.
Navigate to data source permissions.
- Go to the Permissions tab of the newly created Prometheus data source. Here, you find the LBAC for data sources rules section.

For more information on how to set up 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 Grafana Enterprise Metrics (GEM), created with basic authentication.

Before you begin

Before you configure LBAC for data sources, ensure you have the following:

Permission to create a cluster in your Grafana.
Admin plugins permissions for Grafana.
Admin data source permissions for Grafana.

Set up a Grafana Enterprise Metrics tenant and access policies

Access the plugins page and install the Grafana Enterprise Metrics plugin.
Connect your plugin and use the app as the cluster.
Access the Grafana Enterprise Metrics app and configure a tenant.
Store the uid of the tenant to use as the username for basic authentication.
Access the policies page inside the app and create an access policy.
- Create an access policy for the Prometheus data source.
- Ensure the access policy includes metrics:read permissions.
- Ensure the access policy doesn’t include labels rules.
- Store the token to use as the password for authentication.

Configure a new Prometheus data source on Grafana Enterprise

Create a new Prometheus data source.
- In Grafana, 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.
- Select Save & test.
Navigate to data source permissions.
- Go to the Permissions tab of the newly created Prometheus data source. Here, you find the LBAC for data sources rules section.

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

Examples of LBAC rules

An LBAC rule is a logql query that filters metrics based on labels. Each rule operates independently as its own filter, separate from other rules within a team. The following examples show common patterns. For more detail, refer to Create LBAC for data sources rules for the Prometheus data source.

Single rule

Multiple label selectors in a single rule are combined with AND. The following rule grants access to metrics that match both job="api-server" and region="europe":

{job="api-server", region="europe"}

Multiple rules

Multiple rules assigned to the same team are combined with OR. The following two rules grant access to metrics that match job="api-server" or region="europe":

{job="api-server"}
{region="europe"}

Match multiple values with a regular expression

Use the =~ operator to match a label against a regular expression. The following rule grants access to metrics in the europe or us-east region:

{region=~"europe|us-east"}

Exclude a label value

Use the != operator to exclude metrics that carry a specific label value. The following rule grants access to all metrics except those labeled cluster="restricted":

{cluster!="restricted"}

User on multiple teams

Users on multiple teams receive access based on all the combined rules assigned to each team, combined with OR. For example, if Team A has {region="europe"} and Team B has {region="us-east"}, a user on both teams can access metrics that match region="europe" or region="us-east".

LBAC for data sources overview explains how LBAC works, which data sources are supported, and current limitations.
Create LBAC for data sources rules for a supported data source explains how to define and manage rules.

Configure LBAC for Tempo or Cloud Traces

Tue, 13 Oct 2026 14:23:35 +0000

Configure LBAC 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.

This document explains how to configure Label-Based Access Control (LBAC) for data sources for a Tempo or Cloud Traces data source. LBAC for data sources lets you restrict which spans a team can access by defining rules based on trace attributes, providing fine-grained, team-based access control within a single tenant. It mirrors the experience used for logs and metrics LBAC in Grafana Cloud.

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

Note
LBAC for traces is available only on Grafana Cloud. It isn’t available in Grafana Enterprise. It applies only to the Cloud-provisioned Tempo or Cloud Traces data source that Grafana hosts, not to self-managed data sources.

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

How LBAC works

When a user queries a tracing data source, Grafana evaluates the user’s team memberships and the LBAC rules assigned to those teams. Grafana adds these rules 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 are combined with AND (,), while multiple rules across teams are combined with OR.

If none of a user’s teams have LBAC rules for the data source, that user can query all traces, subject to their data source permissions.

Before you begin

Before you configure LBAC for data sources, ensure you have the following:

Permission to create a Tempo or Cloud Traces tenant in Grafana Cloud.
Administrator permissions for Grafana.
A team set up in Grafana.

Known limitations

Be aware of the following limitations for traces LBAC:

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.
Rules are restricted to resource scope attributes.
Users with multiple rules may experience a slight performance degradation.

Configure a new Tempo or Cloud Traces data source

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 source details for your stack.
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 the Tempo or Cloud Traces data source, or create a new one.
Navigate back to the Tempo or Cloud Traces data source.
- Set up the data source using basic authentication. Use the userID or tenantID as the username. Use the token from your access policy as the password.
- Select Save & test.
Go to the Permissions tab of the newly created data source. Here, you find the LBAC for data sources rules section.
Choose a team from the Team drop-down.

Enter attribute selectors, such as:

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

Select Save.

Examples of LBAC rules

An LBAC rule for traces is an attribute selector that filters spans based on trace attributes. Each rule operates independently as its own filter, separate from other rules within a team.

Follow these guidelines when you write rules:

Use only resource scope attributes, for example { resource.env="prod" }.
Use double quotes for string values. Only string values are supported.
Use the =~ operator for regular expression matching, for example { resource.team =~ "team-a|team-b" }.
If you use negation (!= or !~), refer to Troubleshoot missing service traces. TraceQL negation behaves differently from PromQL when an attribute is missing.
Use up to two conditions in a single rule, separated by a comma (,), which acts as an AND operator.

For more detail, refer to Create LBAC for data sources rules for a supported data source.

Single rule

Multiple conditions in a single rule are combined with AND. The following rule grants access to spans that match both resource.service.name="payments-api" and resource.env="prod":

{ resource.service.name="payments-api", resource.env="prod" }

Match multiple values with a regular expression

Use the =~ operator to match an attribute against a regular expression. The following rule grants access to spans from team-a or team-b:

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

Multiple rules

Multiple rules assigned to the same team are combined with OR. The following two rules grant access to spans in the prod environment or spans from the billing team:

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

User on multiple teams

Users on multiple teams receive access based on all the combined rules assigned to each team, combined with OR. For example, if the teams have the following rules:

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

A user on both teams can access spans that match resource.cluster="us-east-1" or resource.service.name="frontend".

How LBAC affects returned data

How LBAC filters data depends on the endpoint:

Trace-by-ID lookups use one of three redaction modes, described in the following sections, that control how non-matching spans are handled.
Search, metrics, and autocomplete endpoints always return only the spans that match the LBAC rules, regardless of the configured redaction mode.

Cloud Traces supports three redaction modes for trace-by-ID lookups. The active mode is configured per tenant. To change the mode for your organization, contact Grafana Support.

Mode	Non-matching spans	Best for
Attributes (default)	Kept, but attributes and intrinsics redacted	Preserving trace structure
Spans	Removed entirely	Hiding the existence of spans (may break traces)
Error	Entire request returns a `404`	Strict, all-or-nothing visibility

Attributes mode (default)

Non-matching spans are included in the response, but their attributes and intrinsics are 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’re never redacted, even on 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 doesn’t match the LBAC policy, the entire request returns a 404 error. This is the strictest mode and suits environments where partial trace visibility isn’t acceptable.

Troubleshoot missing service traces

If a team can’t see traces from a service you expect, a negation rule combined with a missing attribute may be excluding those spans.

If you’re familiar with PromQL label matching, TraceQL attribute selectors behave differently for negation.

In PromQL, labelFoo != "abc" matches series that don’t have labelFoo or have a value other than "abc". In TraceQL, resource.attr != "abc" and resource.attr !~ "abc" match only spans that have resource.attr and whose value matches the condition. Spans that don’t include that attribute aren’t returned.

This difference matters when you combine attributes in one rule with , (AND). For example, this rule matches only spans from checkout-api that also have the resource.k8s.namespace.name attribute. Services such as checkout-api that don’t set resource.k8s.namespace.name won’t match, even if you want to include them.

{ resource.service.name="checkout-api", resource.k8s.namespace.name !~ "prod-main" }

To include services that don’t set the attribute, add a separate rule for each service. Multiple rules for a team combine with OR:

{ resource.service.name="checkout-api", resource.k8s.namespace.name !~ "prod-main" }
{ resource.service.name="checkout-api" }

Add similar OR rules for other services that don’t set the namespace attribute.

To find services that don’t set an attribute, run this query in Grafana Explore:

{ resource.k8s.namespace.name = nil } | rate() by (resource.service.name)

This query returns services that don’t have resource.k8s.namespace.name set.

Manage LBAC rules

You can edit or delete existing LBAC rules from the data source’s Permissions tab.

Edit an LBAC rule

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 select the pencil (edit) icon.
Modify the Attribute filters.
Select Save.

Delete an LBAC rule

Open your stack and select your Tempo or Cloud Traces data source.
Select Permissions.
Scroll to Data access.
Select the rule you want to delete.
Select the X (delete) icon.
Confirm the deletion.

LBAC for data sources overview explains how LBAC works, which data sources are supported, and current limitations.
Create LBAC for data sources rules for a supported data source explains how to define and manage rules.
Construct a TraceQL query explains attribute selector syntax, including !=, !~, and = nil.
Search traces using the query builder explains how to run the diagnostic query in Explore.

Label-based access control (LBAC) for data sources on Grafana Labs

Create LBAC for data sources rules

Create LBAC for data sources rules

Before you begin

Create an LBAC for data sources rule for a team

LBAC rules

Traces rules

Best practices

Examples

One rule for each team

Multiple rules for one team

Exclude a label for a team

Rules with multiple conditions

Rules that overlap

Team without a rule

Administrator on a team with a rule

Next steps

Configure LBAC for a Loki data source

Configure LBAC for a Loki data source

Grafana Cloud

Before you begin

Configure a new Loki data source on Grafana Cloud

Grafana Enterprise

Before you begin

Set up a Grafana Enterprise Logs tenant and access policies

Configure a new Loki data source on Grafana Enterprise

Examples of LBAC rules

Single rule

Multiple rules

Match multiple values with a regular expression

Exclude a label value

User on multiple teams

Related resources

Configure LBAC for a Prometheus data source

Configure LBAC for a Prometheus data source

Grafana Cloud

Before you begin

Configure a new Prometheus data source on Grafana Cloud

Grafana Enterprise

Before you begin

Set up a Grafana Enterprise Metrics tenant and access policies

Configure a new Prometheus data source on Grafana Enterprise

Examples of LBAC rules

Single rule

Multiple rules

Match multiple values with a regular expression

Exclude a label value

User on multiple teams

Related resources

Configure LBAC for Tempo or Cloud Traces

Configure LBAC for Tempo or Cloud Traces

How LBAC works

Before you begin

Known limitations

Configure a new Tempo or Cloud Traces data source

Examples of LBAC rules

Single rule

Match multiple values with a regular expression

Multiple rules

User on multiple teams

How LBAC affects returned data

Attributes mode (default)

Spans mode

Error mode

Troubleshoot missing service traces

Manage LBAC rules

Edit an LBAC rule

Delete an LBAC rule

Related resources