A Grafana service account token lets whoever holds it call the Grafana HTTP API as the service account it belongs to. The service account has a role, such as Viewer, Editor or Admin, and the token inherits that role. An Editor or Admin token can change dashboards, alert rules and data source settings, and data source settings often include credentials for the databases and cloud accounts behind them. A leaked token is therefore a way into everything Grafana connects to. Revoke it first, then look at what it changed.
Check your GitHub account for leaked secrets — free
- Provider
- Grafana
- Severity
- Critical
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What a Grafana Service Account Token looks like
A Grafana service account token starts with glsa_, followed by 32 letters and digits, an underscore, and an 8-character checksum made of hexadecimal characters. The masked shape looks like this:
glsa_…XXXX_XXXXXXXX Grafana service account token (masked)
Grafana writes the token once, when it is created, and it cannot be shown again. The checksum at the end lets Grafana reject mistyped values, which also means a copied value is either exactly right or not usable. The token belongs to a service account, not to a person, so it keeps working when the person who created it leaves the team. That makes it easy to forget and easy to miss in a review.
Grafana Cloud also has access policy tokens, which are a separate system. This guide covers service account tokens. If the value you found does not start with glsa_, check the access policies in your Grafana Cloud account instead.
How Grafana Service Account Tokens get leaked
- Provisioning files. A data source or alerting file in a repository that holds the token in plain text instead of an environment variable.
- Terraform and scripts. A provider block or an API call with the token written inline, then pushed with the rest of the code.
- Dashboard exports. A JSON export or a provisioning file that includes the token through a data source reference, shared in a repository or a ticket.
- Container images. A token baked into a Docker image or a Helm values file, then published to a public registry.
- Build logs. A debug step that prints the HTTP headers of a call to the Grafana API, which contains
Authorization: Bearer glsa_….
What to do in the first hour
- Delete the exposed token first. Open the service account that owns it in Grafana, and delete the token. Deleting ends its access at once, so do it before you clean the repository.
- Create a replacement for the integration that needs one. Give the service account the lowest role that works, and set an expiry date on the token, so that a future leak has a shorter life.
- Deploy the replacement to the pipeline, provisioning system or script that used the old value, and confirm that dashboards still load and alerts still evaluate.
- Check the audit log. Grafana Enterprise and Grafana Cloud record administrative actions. Review them for the period since the exposure. Look for dashboards, folders and alert rules that were created, changed or deleted by the service account, and for changes to data sources.
- Review data sources. Open each data source the service account can reach and check its URL and its credentials. If a data source was changed, restore the original settings and rotate the credential it uses, since the old one may have been read.
- Check other service accounts. Look at the other tokens and service accounts in the same organization, and remove any you cannot place. Pay attention to accounts with the Admin role.
- Clean the repository and look for other secrets stored in the same files. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at Grafana
Service accounts are managed from the Administration area of your Grafana instance, under Users and access, then Service accounts. Open the account that owns the leaked token, find the token in its list by its name and creation date, and delete it. The same can be done through the HTTP API with a token that has permission to write service accounts. Grafana’s documentation covers both routes, and the layout can differ between versions and between self-hosted and cloud installations, so if a menu does not match this description, follow the service account documentation for your version.
How LeakWatch detects it
The rule is called Grafana Service Account Token. It looks for the prefix glsa_ in any letter case, followed by 32 letters or digits, an underscore, and 8 hexadecimal characters, with a word boundary before the prefix and a boundary after the value, such as a quote, a space, a semicolon or the end of the line. A value with the wrong length or a different structure is not reported. The severity is critical. This type is not checked live: LeakWatch does not send any request to Grafana with the token it found, so the detection is the only signal, and the token should be revoked by you.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone change my dashboards and alerts with this token?
Yes, if the service account has the Editor or Admin role. An Admin token can also change users, data sources and plugins. Check the role of the account before you decide how urgent the review is.
Will deleting the token affect the dashboards themselves?
No. Dashboards and alert rules stay in place. Only the integration that used the token loses access, so it needs the replacement before the old token is deleted.
Is a short expiry enough?
It limits how long a leaked token stays useful, but it does not stop an attacker who uses it in that window. Set an expiry as a default and still revoke the token as soon as you see a leak.