Tokens
Tokens
Scoping, rotation and the blast radius of a leak.
Every request carries a token. Tokens are scoped by action and by dataset, and the difference between a good day and a bad one is usually how narrowly they were scoped.
Scopes
| Scope | Allows |
|---|---|
ingest | Writing events. Cannot read anything back |
query | Reading events and running LSQL |
monitors | Creating and editing alerting rules |
dashboards | Creating and editing dashboards |
admin | Everything, including issuing further tokens |
ingest cannot read
This is the important one. A shipper token on a hundred edge nodes should be
ingest on one dataset — if it leaks, the attacker can write noise, not read your logs.Rotating without downtime
- 1.Create a second token with the same scopes.
- 2.Deploy it. Both work simultaneously.
- 3.Watch
last_used_aton the old token until it stops moving. - 4.Delete the old one. Revocation propagates within seconds.
POST /v1/tokens/{id}/regenerate exists but invalidates the old secret immediately — it is for a leak, not for a routine rotation.
If one leaks
- 1.Delete it — do not regenerate. Deleting is unambiguous in the audit log.
- 2.Check the audit log for what it did, filtered by token id.
- 3.If it had
query, treat every dataset it could reach as disclosed. - 4.Re-issue with narrower scopes than it had.