Problem
Post-NixOS migration, almost all automation paths use openbao-agent's CIDR-bound AppRole flow, which mints fresh tokens on demand. But there are likely some static long-lived tokens still floating around — operational tokens, break-glass tokens, possibly stale ones from migration-era one-offs. Today there's no visibility into:
- What tokens exist in the OpenBao token store
- Which are close to TTL expiry (and would expire silently)
- Whether any could be AppRole-ified instead
Proposed approach
One-shot interactive audit (not yet automation):
- List token accessors:
bao list auth/token/accessors
- For each accessor:
bao token lookup -accessor=<id> to get policies, display name, TTL, creation time
- Capture in a table: token name, policies, TTL remaining, what it's used for (if known)
- Decide per-token:
- Delete if stale
- AppRole-ify if it's a service-account use case
- Keep as static if there's a real reason (and document why)
After the one-shot pass, decide whether ongoing audit automation is worth building (likely yes if there are >3 surviving static tokens; probably no if there are 0–2).
Acceptance criteria
Related
Problem
Post-NixOS migration, almost all automation paths use openbao-agent's CIDR-bound AppRole flow, which mints fresh tokens on demand. But there are likely some static long-lived tokens still floating around — operational tokens, break-glass tokens, possibly stale ones from migration-era one-offs. Today there's no visibility into:
Proposed approach
One-shot interactive audit (not yet automation):
bao list auth/token/accessorsbao token lookup -accessor=<id>to get policies, display name, TTL, creation timeAfter the one-shot pass, decide whether ongoing audit automation is worth building (likely yes if there are >3 surviving static tokens; probably no if there are 0–2).
Acceptance criteria
docs/)Related