How to scale access control in Grafana Cloud

One of the primary reasons organizations adopt Grafana Cloud is to create a single pane of glass across the data they collect from self-hosted systems, cloud providers, and third-party platforms. Bringing those signals together enables richer correlations, reduces tool sprawl, and makes it easier for teams to understand what's happening across their environment.

But as observability grows and becomes more centralized, access management becomes more important. When infrastructure metrics, application logs, business KPIs, and customer-specific data all live in the same platform, organizations need a scalable way to ensure the right people have access to the right resources without creating additional administrative overhead.

The good news is this can all be done directly in Grafana Cloud. To illustrate how this can work in practice, let's look at a fictional company modeled after a common scenario.

Meet AcmeCloud (and the challenge of manual provisioning access) 

AcmeCloud, a platform-as-a-service provider, has set up a new Grafana Cloud instance to visualize infrastructure metrics, business metrics, sensitive application logs pertaining to each of their customers, and more—all in one place. Now they need to provision access across their organization.

They have hundreds of users that require access, and different roles have different needs:

• Admins need full control of data and users
• SREs need to configure data sources, explore telemetry, and build dashboards
• Contractors, working on behalf of specific AcmeCloud customers, need to log in but only to see the dashboards and data relevant to their tenant

At this scale, manual provisioning isn't an option. Neither is trying to keep users in sync between AcmeCloud's identity provider and Grafana Cloud by hand. It's simply too time-consuming and too prone to errors.

For organizations facing similar growth, this is often the point where access management starts to become a scalability challenge rather than an administrative task.

Establishing a single source of truth with SSO and SCIM

Instead of handling everything manually, AcmeCloud relies on SSO (Single Sign-On) for authentication and SCIM (System for Cross-domain Identity Management) for provisioning.

SSO handles how users logged in, while SCIM ensures the right users and groups are automatically available in Grafana Cloud. There are many options for authenticating users in Grafana Cloud, including native integrations with identity providers as well as support for generic authentication methods. To see the full list of supported methods and integrations, read more here.

As users are added, removed, or updated in the identity provider, those changes are reflected in Grafana Cloud automatically. The same concept applies to groups, which are mapped directly to Grafana teams. Groups within the identity provider typically organize users by job function, which correlate to a Grafana team in most cases, since users working in the same role typically have the same use cases and permission levels.

The result is a single source of truth for identity, with no need to manually reconcile users or worry about configuration drift.

For organizations implementing this approach, Grafana's SSO and SCIM integrations make it possible to manage users and groups from the identity provider rather than treating Grafana as a separate identity system.

If you are new to the concept of SCIM provisioning, check out this blog to learn more.

Tip: Establish clear group naming conventions in your identity provider before enabling SCIM. It makes permission mapping significantly easier as your environment grows.

Building a layered access model with RBAC

With users now syncing into Grafana Cloud, the next step is defining what those users can actually do.

AcmeCloud opts to manage access primarily through role-based access control (RBAC).This helps to maintain scalability while providing greater flexibility and security through a combination of basic roles, team memberships, and resource-level permissions. Dive deeper on creating a RBAC strategy and configuration through the guidance in our documentation.

Basic roles in Grafana set the foundation, with assignments mapped from the identity provider: 

• Admins are assigned the Admin role
• Internal AcmeCloud users from the SRE team receive the Editor role
• Contractors receive no basic role at all 

This allows the internal SRE team to access dashboards and data broadly. They can build dashboards and alerts, as well as query metrics, logs, and traces across all tenants. All that is missing now is the ability to configure or alter data sources.

Contractors can log in, but they're presented with an empty Grafana experience by default. For now, there are no available actions to take in Grafana, but they need the ability to view dashboards based on data solely containing their own tenant id.

To build on the permissions provided through basic roles, teams that were provisioned through SCIM are used to layer on additional access.

Users inherit permissions from both their basic role and any teams they belong to. This is an important distinction: permissions in Grafana are additive, not restrictive. A user's effective access is the combination of all assigned roles and team memberships.

For internal users from the SRE team, a shared team is granted additional capabilities, including the ability to configure and manage data sources. This extends their access beyond what the Editor role provides by default.

For organizations designing their own access model, a useful starting point is to assign the minimum role required and then use teams to grant additional capabilities as needed.

Tip: Avoid using highly permissive basic roles as a shortcut. Teams are often a more scalable way to manage access as responsibilities evolve.

Restricting dashboard visibility with teams and folders

Contractors are grouped into tenant-specific teams, with no additional capabilities added at that level. Instead, access is controlled through folder permissions.

Each team is given view access to a specific dashboard folder, so contractors can only see only the dashboards relevant to their tenant and nothing else.

Folder permissions provided a simple and scalable way to partition dashboard visibility without creating separate Grafana instances for every customer.

For AcmeCloud, this approach balanced operational simplicity with tenant isolation. Organizations managing multiple customers, business units, or environments often find folder permissions to be one of the simplest ways to segment dashboard access.

Tip: Design your folder structure with future growth in mind. Reorganizing hundreds of dashboards later can become a significant effort.

Enforcing data-level isolation with LBAC

Up to this point, AcmeCloud has been using RBAC to determine what users could access within Grafana Cloud. But dashboard visibility and permissions were only part of the problem. 

AcmeCloud also needs to ensure that access to dashboards doesn't automatically mean access to all underlying data. This is where label-based access control (LBAC) came into play.

By using LBAC, data is scoped by the tenant. That way, even if a user has access to a dashboard, queries are restricted so they only return data associated with their assigned tenant. Read more here for guidance on configuration and limitations.

This adds a final layer of protection, ensuring that customer data remains isolated-even within a shared Grafana instance.

For organizations operating multi-tenant environments, this distinction is important. Dashboard permissions control what users can see, but data-level controls determine what data they can access. Both are required to build a complete access strategy.

Delivering the right experience for every user

From the contractor's perspective, the experience is intentionally limited.

After logging in via SSO, they're placed into their tenant-specific team and land on a predefined home dashboard. They can only view the dashboards within their assigned folder and they can't explore beyond that scope—no visibility into other tenants, and no risk of accessing unrelated data.

What made this setup work isn't any single feature. Instead, it's how all these features are combined to address scalability, flexibility, and security demands.

SCIM handles scale and lifecycle management. RBAC—implemented through basic roles, teams, and folder permissions—defines who can access resources. LBAC then ensures data-level isolation within those resources.

Individually, each of these capabilities is straightforward. Together, they form a layered access model that allows organizations to onboard large numbers of users, both internal and external, without sacrificing control.

Bringing it all together

As Grafana usage grows, access management becomes just as important as observability itself. Designing around user types, scope, and data boundaries from the start makes it possible to scale confidently without losing track of who can see and do what.

The AcmeCloud example demonstrates a pattern that many organizations can adopt: centralize identity with SSO and SCIM, use roles and teams to define capabilities, control visibility through folders, and enforce data isolation with LBAC.

A single pane of glass doesn't have to mean broad access to everything. With a layered approach to access control, organizations can centralize observability while still maintaining the security and governance required as their environments grow.

Grafana Cloud is the easiest way to get started with metrics, logs, traces, dashboards, and more. We have a generous forever-free tier and plans for every use case. Sign up for free now!