Documentation Grafana Cloud Observe and act Test and validate Performance testing Manage projects and users Configure LBAC

Configure label-based access control in Performance testing

Performance testing stores test result metrics in Grafana Cloud Metrics, which is powered by Mimir. That means test result metrics work like any other metrics in your Grafana Cloud stack: any user with query access to your stack’s Prometheus data source can query the raw metrics, for example to build custom dashboards. Refer to Test result metrics for details on how these metrics are stored and how to query them.

Project permissions only apply within the Performance testing app. They don’t restrict raw metric queries made through the Prometheus data source. If you use RBAC to control which users can view test results, you can configure label-based access control (LBAC) so that access to raw metrics follows the same boundaries as your projects.

You can restrict access to Performance testing metrics in two ways:

• LBAC for data sources: Configure rules on a Prometheus data source that filter which metrics each Grafana team can query. Use this method to control what users can see when they query metrics in Grafana, for example in Explore or dashboards.
• LBAC with access policies: Add label selectors to a Grafana Cloud access policy, so that any token created from that policy can only read metrics that match the selectors. Use this method to control access for tokens, for example for API access or for a data source that authenticates with that token.

Restrict metrics by project

Performance testing metrics include labels, such as k6_cloud_project_id and k6_cloud_test_id, that identify the project and test that each metric belongs to. Refer to Labels for the full list.

Use the k6_cloud_project_id label in LBAC rules and access policy label selectors to restrict access on a per-project basis. Prefer the ID labels over the name labels in access rules, because projects and tests can be renamed, but their IDs never change. For example:

promql Copy

{k6_cloud_project_id="<PROJECT_ID>"}

Replace <PROJECT_ID> with the ID of your project. Refer to Project ID for details on how to find the ID of a project.

Test result metrics use the k6 metric names, prefixed with k6_. For example, the http_req_duration metric is stored as k6_http_req_duration. Refer to Metric names for details.

Users and tokens restricted by this selector can only query test result metrics from that project. For example, consider the following query, which returns the 95th percentile of the k6_http_req_duration metric, aggregated by test and URL:

promql Copy

histogram_quantile(0.95, sum by (k6_cloud_project_name, k6_cloud_test_name, url) (rate(k6_http_req_duration{}[$__rate_interval])))

If LBAC is configured, this query only returns results for tests in the projects that the user or token has access to.

Configure LBAC for the data source

You can’t apply LBAC rules to provisioned data sources, such as the default Prometheus data source in your Grafana Cloud stack. If you try to add LBAC rules to a provisioned data source, you get the following message: Please contact your server admin to update this data source.

Instead, create a new Prometheus data source that uses the same connection details as the provisioned one, and configure LBAC rules on the new data source:

1. Create a new Prometheus data source that uses the same credentials as the provisioned data source. Refer to Configure LBAC for data sources for Prometheus for details.
2. Assign query permissions to the Grafana Team you want to grant access to.
3. Add LBAC rules for each team, for example using the k6_cloud_project_id label. Refer to Create LBAC for data sources rules for details.

Configure LBAC with an access policy

If users or services access Performance testing metrics using an access policy token, for example through the API or a custom data source, you can restrict which metrics that token can read:

1. Create an access policy with the metrics:read scope.
2. Add a label selector to the access policy, for example using the k6_cloud_project_id label.
3. Create a token for the access policy and use it to authenticate your API requests or data source.

Refer to Use label-based access control (LBAC) with access policies for details.