Skip to main content
ConfigView reads Grafana Cloud through two separate APIs that use two separate credentials, so Grafana Cloud appears in ConfigView as two integrations that share this page: You can set up either one or both. They do not depend on each other. The stack integration also works for self-hosted Grafana.
A Cloud Access Policy token cannot read a stack, and a stack service account token cannot read grafana.com. That is Grafana’s design, not a ConfigView limit. It is why there are two sets of secrets.
ConfigView only reads. It never creates, changes or deletes anything in Grafana, and it never stores token values, client secrets or data source passwords.

Part 1: Grafana Cloud (organization)

You will end up with 2 required secrets (GRAFANA_CLOUD_TOKEN, GRAFANA_ORG_SLUG).

What you need

  • Grafana Cloud organization admin rights (to create an access policy)

Step 1: Open the Grafana Cloud page in ConfigView

Open ConfigView in a second browser tab and leave it open: https://{companyname}.configview.com/admin/integrations/grafana

Step 2: Create a read-only access policy and token

  1. Sign in to Grafana Cloud and open Administration → Users and access → Cloud access policies (in the Cloud Portal: Security → Access Policies)
  2. Click Create access policy. Name it ConfigView
  3. Set the realm to your whole organization
  4. Tick only these scopes:
Don’t tick any :write or :delete scope. ConfigView never uses them.
  1. Click Create, then Add token on the new policy. Give it an expiry date you will remember to renew, and copy the token (it starts glc_ and is shown once)
  2. In the ConfigView tab, paste it into GRAFANA_CLOUD_TOKEN and save
  3. Enter your organization slug in GRAFANA_ORG_SLUG. It is the last part of https://grafana.com/orgs/<slug>: not the display name and not a stack name

Step 3: Connect and verify

Click Connect, then Verify now. The health check reads both secrets, reads the organization, lists your stacks, then tries one access policy, one token and the member list. If a check fails:
  • 401. The token is wrong, expired or deleted. Create a new one.
  • 403 on a step. The access policy lacks that scope (see the table).
  • 404 on the organization. GRAFANA_ORG_SLUG is wrong, or the policy belongs to a different organization.
  • Organization Members shows as skipped. The org-members:read scope is missing. This area is optional.
  • Access policies says no regions are known. The organization has no stacks, so there is nothing to read.

Part 2: Grafana Cloud - Stack

You will end up with 2 required secrets (GRAFANA_STACK_URL, GRAFANA_STACK_TOKEN). One integration reads one stack; add a second Grafana Cloud - Stack instance for another stack.

What you need

  • Admin rights in the stack (to create a service account)

Step 1: Open the page in ConfigView

https://{companyname}.configview.com/admin/integrations/grafana-stack

Step 2: Create a service account and token

  1. In your stack, open Administration → Users and access → Service accounts and click Add service account. Name it ConfigView
  2. Choose the role. Viewer is not enough: in Grafana, the Viewer and Editor roles cannot list users, teams, service accounts or data sources. Choose Admin.
    • If you are on Grafana Cloud Pro or Enterprise you can instead give the service account a custom role that holds only read permissions: org.users:read, teams:read, teams.permissions:read, serviceaccounts:read and datasources:read (plus settings:read for SSO providers). That is the safest option because the token cannot change anything.
  3. On the service account, click Add service account token. Set an expiry and copy the token (it starts glsa_ and is shown once)
  4. In ConfigView, paste it into GRAFANA_STACK_TOKEN
  5. Enter the stack address in GRAFANA_STACK_URL, for example https://acme.grafana.net. You find it in the Cloud Portal under your stack’s Details
An Admin service account token can change Grafana. Store it only in ConfigView, give it an expiry, and use the custom role above where your plan allows.

Step 3: Connect and verify

Click Connect, then Verify now. The health check reads both secrets, calls the stack, then tries each area. Areas the token cannot read are shown as skipped, and if the token reaches nothing it says so. If a check fails:
  • 401. The token is wrong, expired or disabled, or it is a glc_ Cloud Access Policy token. A stack needs a glsa_ service account token.
  • Everything but the stack check is skipped. The service account is a Viewer. Give it the Admin role or the custom role above.

Data Tables

Each table has a run_at column and a raw_json column holding the record as Grafana returned it, minus anything listed under What isn’t collected. Each table keeps only the newest run.

Things worth knowing

Access policies are read per region. Grafana lists them one region at a time, so ConfigView reads the regions where your organization has a stack. A policy created in a region with no stack is not seen. Write scopes are not all alike. metrics:write or logs:write only lets a token send data. ConfigView separates those from scopes on accesspolicies, stacks, orgs, org-members and stack-service-accounts, which let a token create more access (can_manage_org). “Never expires” is a finding. A token with no expiry works until someone deletes it. Both token tables mark them, and the catalog lists them. Last-used dates. Cloud Access Policy tokens report first and last use. Service account tokens report creation and expiry; ConfigView also stores a last-used date if your Grafana version returns one. Single stack, single organization. A service account token belongs to one organization of one stack, so the stack integration lists that organization’s users. Rate limits. Grafana documents 600 requests per hour for the access policy endpoints; the collectors stay under it. It publishes no limit for the other endpoints. Collectors pace themselves and wait if Grafana answers 429.

What isn’t collected

  • Access policy token values, service account token values and legacy API key values
  • Data source passwords, basic auth users, secureJsonData, jsonData and the full data source URL (only its scheme and host are kept)
  • SSO client secrets, private keys, certificates and signing keys
  • Dashboards, folders, alert rules, query data and any metrics, logs or traces
  • Billing, invoices and payment details