A service-account token lets a machine or a script read a vault without anyone signing in. The Kubernetes operator and the CLI both authenticate with one.

A token is bound to one environment of one vault. It cannot see any other vault, nor another environment of the same vault, so a leaked token exposes exactly one set of secrets. Mint one per consumer: one per cluster, one per pipeline.

Creating a token

Managing tokens takes the admin role on the vault. From Developers > Tokens in the app, pick the vault and the environment, then New token. Give it a label that says who uses it, for instance prod-cluster, and a role:

Role	Can
viewer	Read secret values. Enough for the operator.
writer	Read, create and rotate secrets.
admin	Everything a writer can.

A token can carry an expiry date. Without one it stays valid until revoked.

The token is shown once, right after it is created, and starts with fvsat_. FerrVault only keeps a hash of it and a short preview, so a lost token cannot be shown again: revoke it and mint a new one.

Revoking a token

The token list shows each token's label, role and when it was last used. Revoke takes effect immediately: the next request made with that token is refused. A token that has never been used, or not for a long time, is a good candidate for revocation.

When the person who minted a token loses access, what they minted goes with it: leaving the organization revokes every token they created in it, losing their grant on a vault revokes the ones they created in that vault, and a downgrade revokes only the ones that outrank their new role. They knew those token strings, so the access ending has to end them.