sys-token-store
Description
sys-token-store is a lightweight Ansible helper role for resolving and persisting per-user application tokens in a unified and idempotent way.
It provides a single source of truth for application tokens while keeping runtime usage simple and consistent across roles.
The role is intentionally not a secret generator.
It only stores and propagates tokens that already exist (e.g. created by bootstrap processes or provided externally).
Overview
This role stores and manages per-user application tokens in a local YAML store file (idempotent read/write helpers).
Features
- Automated provisioning: Configured by Ansible without manual steps.
Core Principles
- Single logic for all roles
- Always resolve tokens as:
users → token store → empty
- Always resolve tokens as:
- No implicit token generation
- Empty tokens are rejected
- Idempotent persistence
- Store file is only rewritten when content actually changes
- Lookup-based runtime resolution
- Tokens are resolved through
lookup('users'), which hydrates from the store on each lookup call
- Tokens are resolved through
- Case-sensitive keys
- User keys and application IDs must match exactly
Token Resolution Order
When resolving a token, the following order is used:
lookup('users', '<user>').tokens.<application_id>- Token store file (
tokens.yml) - Empty string (
'')
No automatic fallback generation happens.
Store Format
Tokens are stored in a single YAML file:
users:
administrator:
tokens:
web-app-matomo: "46e50b0eb52d0d141a7d6cf9b3d0b3e2"
Default location:
/var/lib/infinito/secrets/tokens.yml
Permissions are restricted to root by default.
Provided Tasks
write.yml
Persists a token so it is available through the users lookup on subsequent reads.
This is the canonical way to store tokens.
Input
sys_token_store_user_keysys_token_store_appsys_token_store_token(must be non-empty)
Effects
- Updates the token store file (idempotent)
- Makes the token available via
lookup('users', '<user>').tokens['<app>'] - Exports
sys_token_store_token
Empty tokens are rejected explicitly.
Usage Examples
Persist a token
- include_role:
name: sys-token-store
tasks_from: write.yml
vars:
sys_token_store_user_key: administrator
sys_token_store_app: web-app-matomo
sys_token_store_token: "{{ matomo_token_value }}"
After this, the token is available as:
lookup('users', 'administrator').tokens['web-app-matomo']
What This Role Does Not Do
- ❌ No token generation
- ❌ No encryption
- ❌ No user management
- ❌ No application-specific logic
It is a generic infrastructure helper.
Best Practices
- Keep all user and application keys lowercase
- Use stable
application_idvalues - Let application roles create tokens
- Let
sys-token-storehandle persistence