Grafana Service Account & Token Management Prompt

You are a senior Grafana platform engineer who runs authentication and automation access at scale.

I will provide:
- The current API keys in use and what automation consumes them
- The Grafana version and whether it is OSS, Enterprise, or Cloud
- The RBAC model (org roles, or fine-grained RBAC on Enterprise)

Your job:

1. **Inventory legacy API keys**: enumerate existing keys, their roles, and the jobs/CI that use them so nothing breaks on cutover.
2. **Map keys to service accounts**: each automation identity becomes one service account with a least-privilege role (Viewer/Editor/Admin, or a fine-grained RBAC role on Enterprise), never a shared Admin key.
3. **Migrate**: use the built-in "migrate to service accounts" flow or the API, preserving the token so consumers keep working during transition.
4. **Token lifecycle**: set token expiry (`secondsToLive`), define a rotation cadence, and document where each token is stored (secret manager, not a repo).
5. **Provisioning as code**: express service accounts and role assignments idempotently (Terraform `grafana_service_account` + `grafana_service_account_token`, or the HTTP API in a bootstrap script).
6. **Least privilege check**: flag any account with more scope than its job needs and propose the tighter role.
7. **Cleanup**: after cutover, delete the legacy API keys and verify no job still references them.

Mark DESTRUCTIVE: deleting API keys or reducing a service account's role can break running automation — sequence the migration so tokens overlap before old keys are revoked.

---

Current API keys and consumers: [DESCRIBE]
Grafana edition/version: [DESCRIBE]
RBAC model: [DESCRIBE]

Why this prompt works

Grafana deprecated standalone API keys in favor of service accounts, and most teams still run shared Admin keys with no expiry. This prompt drives a safe, overlapping migration — inventory, least-privilege mapping, token overlap, then cleanup — and delivers it as idempotent code instead of click-ops, which is the only way it stays correct across a fleet.

How to use it

1. List every consumer of each key so nothing is orphaned on cutover.
2. State the edition so RBAC advice matches OSS vs Enterprise.
3. Ask for the Terraform so the accounts are reproducible and auditable.
4. Confirm the revoke step is last so live jobs never lose access.

Useful commands

# Create a service account and a scoped token via the API
curl -X POST http://localhost:3000/api/serviceaccounts \
  -H "Authorization: Bearer $GRAFANA_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"ci-dashboard-deployer","role":"Editor"}'

curl -X POST http://localhost:3000/api/serviceaccounts/2/tokens \
  -H "Authorization: Bearer $GRAFANA_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"ci-token","secondsToLive":2592000}'   # 30-day expiry

# List remaining legacy API keys to confirm cleanup
curl -s -H "Authorization: Bearer $GRAFANA_ADMIN_TOKEN" \
  http://localhost:3000/api/auth/keys | jq '.[].name'

Example config

# Terraform: least-privilege service account with an expiring token
resource "grafana_service_account" "ci_deployer" {
  name = "ci-dashboard-deployer"
  role = "Editor"
}

resource "grafana_service_account_token" "ci_deployer" {
  name               = "ci-token"
  service_account_id = grafana_service_account.ci_deployer.id
  seconds_to_live    = 2592000 # rotate monthly
}

output "ci_token" {
  value     = grafana_service_account_token.ci_deployer.key
  sensitive = true
}

Common findings this catches

• Broken jobs → old key revoked before the new token deployed.
• Over-privilege → shared Admin key doing an Editor’s work.
• Immortal tokens → no secondsToLive, no rotation.
• Leaked secrets → token in a repo or CI log.
• Unprotected state → token in plaintext Terraform state.

When to escalate

• Secret storage and rotation policy — the security/secrets team.
• Fine-grained RBAC role design — the Grafana Enterprise owner.
• CI systems that cannot read from the secret manager — the platform/CI owner.