Grafana Service Accounts Need Organization-Scoped Review
Grafana service accounts provide non-interactive access to dashboards, data sources, alerting, and administration APIs. They are not user accounts. They can remain active after the person who created them leaves, and their tokens inherit the account's permissions. That makes them useful for automation and risky when their organization scope and token inventory are undocumented.
The account and the token are different objects
Grafana's service account documentation describes a service account as a workload identity that can be enabled or disabled, associated with tokens, and granted permissions. A token is a generated string used to authenticate API calls. One service account can have several tokens so that different applications can be audited or rotated separately.
Service accounts work only in the organization where they are created. They cannot perform instance-wide operations such as global user or organization management. This limitation is useful, but it does not limit a token to a single dashboard or data source. Review the account's permissions for the resources it can reach.
Inventory by owner and purpose
For each service account, record the organization, owner, purpose, token names, creation date, last use, and review date. Record the API operations the automation needs. A provisioning account that updates dashboards should not also administer users or data sources.
Use separate service accounts when applications need different permissions or separate audit trails. A single shared account with many tokens can hide which integration made a change. Disable unused tokens and remove accounts that no longer support a running workload.
Check the effective permissions
Grafana exposes permission information through its access-control API. Use the authenticated token to retrieve the service account's effective permissions and compare them with the intended role. The response can reveal a broader role than the integration needs.
Do not rely on the account name as evidence of scope. A name such as monitoring-readonly is documentation, not authorization. Test read, update, and delete operations against non-production resources and record the results.
Rotate without breaking automation
Create a replacement token, update the secret store, run a verification job, and confirm the new token works. Then revoke the old token. Remove the old token from environment variables, CI systems, and deployment manifests.
If a token is exposed, disable it first, review API logs for its activity, and investigate the data sources it could query. A Grafana token may reach backend data sources through the server, so the impact can extend beyond dashboards. Review data source permissions and proxy configuration as part of the response.
Leadership and offboarding
A service account should have an owning team, not a departed employee. Review ownership during role changes and after acquisitions or project closures. Link account ownership to the same access-review system used for human accounts.
Service accounts make Grafana automation auditable when tokens are unique, permissions are narrow, and rotation is routine. The review should answer three questions: which organization contains the account, which API resources can it change, and who can revoke its tokens today.
Top comments (0)