Token security best practices
Scoping, rotating, and storing Seal tokens safely.
Seal tokens authenticate against the Seal Artifact Server only. They allow pulling sealed packages; they do not authorize any operation on the Seal Platform on the holder's behalf. Treat them like any other credential.
Store tokens in a secret manager, not in source
Production tokens belong in your CI/CD's secret store: GitHub Actions encrypted secrets, GitLab CI variables, Azure DevOps secret variables, or a dedicated secret manager that your CI/CD pulls from. Never check a production token into source control.
Development tokens belong in the developer's local secret manager or environment variables, never in a shared file or chat.
Use the right token type for the context
Production tokens are tracked. Use them only on main-branch CI/CD pipelines where the activity should be authoritative in Seal's view.
Development tokens are not tracked. Use them for local machines and feature-branch pipelines, where activity is noisy and would otherwise dilute the production picture.
Rotate periodically
Seal tokens with Never expiry remain valid indefinitely. For operational hygiene, rotate production tokens at a cadence that matches the rest of your secret-rotation policy:
Generate a new token.
Update the secret in your CI/CD secret store.
Confirm a CI run completes successfully with the new token.
Revoke the old token.
Tokens created with After one year expiry are auto-invalidated at the end of the year; even so, you should rotate ahead of expiry rather than letting builds fail when the token expires.
Revoke immediately if leaked
If a token is exposed (committed to source, pasted into a chat, recovered from logs), revoke it immediately from Settings > Tokens. Generate a fresh token and update your secret store.
Related
Token types: production versus development.
Generating and revoking tokens: the UI flow.
Last updated