Grafana Service Accounts & API Tokens Prompt

You are a senior Grafana admin who has migrated from legacy API keys to service accounts and managed automation access at scale.

I will provide:
- The use case (CI/CD posting dashboards, external dashboard provisioning, integration)
- Current state (API keys vs SA)
- Symptom (auth fail, expired, can't access)

Your job:

1. **Service Accounts vs API Keys**:
   - **API Keys** — legacy; org-scoped
   - **Service Accounts** — newer; can have multiple tokens; revocable per token; team-aware
   - Recommendation: migrate to SA
2. **For service account creation**:
   - UI: Administration → Service Accounts
   - API: `/api/serviceaccounts`
   - Org-scoped role (Viewer/Editor/Admin)
3. **For SA tokens**:
   - Generate per use case
   - Optional expiry
   - Rotate independently
4. **For scoping**:
   - SA can be in teams
   - Folder/dashboard permissions via team
   - No fine-grained per-API limits (use external proxy)
5. **For rotation**:
   - Generate new token
   - Update consumer
   - Revoke old
   - No automatic
6. **For audit**:
   - SA actions logged
   - User actions logged
   - Audit log (Enterprise)
7. **For automation patterns**:
   - CI/CD adds annotation on deploy
   - Dashboard sync
   - Alert rule provisioning
8. **For multi-org**:
   - SA per org
   - Token per org

Mark DESTRUCTIVE: SA with admin role for narrow use case, tokens without expiry, leaked SA token used widely (rotate immediately).

---

Use case: [DESCRIBE]
Current state: [DESCRIBE]
Symptom: [DESCRIBE]

Why this prompt works

API access control matters. This prompt walks SA pattern.

How to use it

1. Create SA per integration.
2. Token per use case.
3. Rotate on schedule.
4. Audit usage.

Useful commands

# Create SA
curl -u admin:pass -X POST http://grafana:3000/api/serviceaccounts \
    -H "Content-Type: application/json" \
    -d '{"name":"ci-deploy-notifier", "role":"Editor"}'

# List SAs
curl -u admin:pass http://grafana:3000/api/serviceaccounts/search | jq

# Create token
curl -u admin:pass -X POST http://grafana:3000/api/serviceaccounts/<sa-id>/tokens \
    -H "Content-Type: application/json" \
    -d '{"name":"ci-deploy-token", "secondsToLive": 7776000}'   # 90 days
# Returns: { "key": "<token>" }

# List tokens for SA
curl -u admin:pass http://grafana:3000/api/serviceaccounts/<sa-id>/tokens | jq

# Revoke token
curl -u admin:pass -X DELETE http://grafana:3000/api/serviceaccounts/<sa-id>/tokens/<token-id>

# Use token in another API call
curl -H "Authorization: Bearer <token>" http://grafana:3000/api/dashboards/db

Patterns

CI/CD service account

# Create SA via API or UI
# Role: Editor
# Permissions: post annotations + read dashboards

# In CI:
GRAFANA_TOKEN=$(vault read -field=token secret/grafana/ci)
curl -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
    http://grafana:3000/api/annotations \
    -d '{...}'

Multi-environment service accounts

# Production: grafana-prod-deploy SA
# Staging: grafana-staging-deploy SA
# Dev: grafana-dev-deploy SA

# Different tokens in different secret stores
# Rotation cycle per env

Rotation script

#!/bin/bash
SA_ID=$1
OLD_TOKEN_ID=$2

# Create new token
NEW_TOKEN=$(curl -s -u admin:$PASS -X POST \
    "$GRAFANA/api/serviceaccounts/$SA_ID/tokens" \
    -d '{"name":"rotation-'$(date +%F)'", "secondsToLive": 7776000}' \
    | jq -r .key)

# Update consumer (Vault, etc.)
vault kv put secret/grafana/sa-$SA_ID token="$NEW_TOKEN"

# Test consumer works
# ... validation ...

# Revoke old
curl -u admin:$PASS -X DELETE "$GRAFANA/api/serviceaccounts/$SA_ID/tokens/$OLD_TOKEN_ID"

Common findings this catches

• API key in CI → migrate to SA token.
• Admin role for narrow use → restrict.
• No rotation → schedule.
• Token in committed code → rotate + scrub.
• Multiple consumers same token → split.
• Token expired → renewal process broken.
• Audit missing context → SA name descriptive.

When to escalate

• Org-wide SA strategy — design.
• Compliance access review — security.
• Migration from legacy keys — coordinate.