The Grafana Cloud identity blueprint: balancing security and scale
If you've ever rolled out Grafana Cloud to a growing engineering organization, this pattern may sound familiar:
Everything feels simple at first. You invite a few teammates, give them access, and dashboards start appearing. Then the team grows. Then the number of stacks grows. Over time, a model that once felt fast and empowering starts to feel risky, difficult to understand, and even harder to undo.
This post is about avoiding that moment.
In a previous post, I described the single-stack model, where Grafana teams and folders handle multi-tenancy inside a single Grafana stack. That model scales well operationally, but only if your identity and access approach scales alongside it.
As organizations grow, a new question tends to surface: How do I give engineers fast and automated access to Grafana without turning my entire Grafana Cloud account into a shared administrative surface?
The answer is not more manual role assignments or more process. Instead, it is a layered identity model, with SCIM acting as the mechanism that allows that model to work reliably at scale.
The starting point: standard Grafana Cloud access
Most teams begin with the default Grafana Cloud access model.
Users are added directly in the Grafana Cloud portal and assigned an organization role such as admin, editor, or viewer. That role is automatically inherited as a basic role by every Grafana stack in the account.
Authentication is intentionally simple. Users can sign in with a username and password or with a social login provider such as Google or GitHub. For small teams, this simplicity is a major advantage. You can be productive almost immediately, without investing time in identity integration.
At the same time, this model relies on an assumption that does not hold indefinitely. It assumes that anyone who needs Grafana access should also have account-wide visibility and permissions.
As usage grows, that assumption becomes difficult to defend. Universal access is harder to audit, harder to govern, and riskier to revoke cleanly. The solution is not to abandon simplicity, but to separate where Grafana is administered from where it is actually used.
This diagram shows the default Grafana Cloud access model, where users authenticate through the Grafana Cloud portal and inherit the same organization role across every stack. The simplicity is intentional, but the shared access surface becomes harder to manage as teams and stacks grow.
Why SCIM matters for operating at scale
For organizations using Okta or Entra ID, SCIM provisioning is what makes a layered identity model practical.
Rather than manually creating and maintaining teams, SCIM allows your identity provider to push users and teams into Grafana automatically, with membership already defined. Your IdP becomes the system of record for who exists and where they belong.
SCIM also enables immediate deprovisioning. When a user is disabled in your identity provider, their access to the Grafana stack is removed in near real-time. This significantly reduces exposure from stale accounts and offboarding gaps.
Just as importantly, SCIM enables day-zero readiness when combined with RBAC, folders, and data source permissions. New engineers arrive to find their dashboards, folders, and team memberships already in place, without manual setup or access requests.
As organizations grow, manual access models do not merely slow things down. They eventually become a source of operational and security risk. With SCIM now generally available for Grafana Cloud stacks, this approach is accessible well before teams reach that breaking point.
Note: SCIM provisioning uses credentials (a token or service account) to automate provisioning. Treat it like an admin credential: store it in a vault/secret manager, rotate it regularly, restrict who can create/manage it, and monitor provisioning activity for anomalies.
Layer one: the Grafana Cloud portal as an administrative vault
The Grafana Cloud portal acts as the control plane for your account. It governs billing, stack creation, support access, and account-level configuration. Because it represents your entire observability footprint, it benefits from being treated as a tightly controlled administrative space.
In practice, this means that access to the portal should be limited to a small group of platform or observability administrators. Most engineers don’t need to sign in to grafana.com at all. Keeping this group small reduces the potential blast radius of mistakes and simplifies compliance and auditing.
Access to the portal is best managed declaratively or through your identity provider. Terraform-based management and private SSO both ensure that authentication strength and lifecycle policies live in your IdP rather than being managed manually in Grafana.
It is also a good practice to maintain a single "break glass" account. This account should not rely on SSO and should be stored securely in a password vault with access reviewed and tested periodically. Its purpose is to ensure you retain access if your identity provider is unavailable.
Bottom line: This layer is intentionally restrictive. The Grafana Cloud portal is designed for operators, not for day-to-day engineering work.
Layer two: the Grafana stack as an automated workspace
The Grafana stack is where engineering teams spend their time. This is where dashboards are explored, alerts are investigated, and incidents are understood.
At this layer, the priority shifts from strict control to predictable automation.
In more security-conscious environments, engineers should authenticate directly against their stack URL, such as your-org.grafana.net. Stack-level SSO reduces the risk that the portal becomes an unintended access path to production data.
User and team creation at the stack level should be driven by your identity provider rather than by manual invitation. Engineers should not have to wait for access to be granted. Ideally, access already exists before they ever sign in.
Even outside of Okta or Entra ID environments, stack-level private SSO using SAML, OIDC, or OAuth allows Grafana to defer authentication decisions to the system you already trust.
This separation is what allows tight governance at the account level while preserving a smooth experience for engineers.
This diagram illustrates a layered identity model, where administrative access to the Grafana Cloud portal is limited and tightly controlled, while engineers authenticate directly to Grafana stacks through the identity provider. SCIM bridges the two layers by synchronizing users and team membership automatically, while org roles and resource permissions are configured separately in Grafana.
As organizations grow, manual access isn't just slow, it can become a security risk. Using SCIM for Grafana stacks (which is now generally available for Okta and Entra ID) lets you automate the boring parts of access control before things get messy.
Once it’s running, you should set up alerts for your provisioning logs to flag anything unusual, such as:
- Unexpected spikes in user creation.
- Bulk deletes or disables that weren't planned.
- Changes to team memberships in sensitive groups.
You can find the technical details in our SCIM documentation, or speak to your account team if you want to try the Private Preview for Grafana Cloud portal SSO.
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!
