The Authentik API token used by estate automation was created by hand in the
UI and pasted into Vault, so it was undocumented, unauditable and impossible
to rotate reproducibly. Model it as config instead.
Add a service_accounts config kind, discovered from config/service_accounts/
like the other kinds. Each entry creates a service_account user, an RBAC role
carrying its global permissions, its API tokens, and (optionally) a kv-v2
write publishing each token key.
Add sa-agent-api granting view_outpost, view_token and view_token_key, with a
non-expiring api token agent-api-token published to kv/service/authentik/agent-api-token.
Introduce a user -> role -> [permissions] model for app access and roles,
managed declaratively.
- Permission groups (akP-<app>-<access>) under config/permissions/: atomic units,
each names the application it grants access to.
- Role groups (akR-<role>) under config/roles/: what users are assigned to;
each nests permission groups via parents (akR-global-admin -> all *-admin,
akR-standard-user -> all *-user). Split into a separate authentik_group
resource so roles can reference permission ids without self-reference.
- Policy bindings gate each application to its permission groups (and, via
child->parent membership propagation, the roles that nest them).
- Hierarchical `groups` scope mapping: walks user groups up through .parents so
the OIDC claim includes inherited permission groups (works around
goauthentik/authentik#15579). Inert until a provider requests the `groups`
scope, so no behaviour change to existing apps until they opt in.
Validated with `tofu validate`.
unkin-agent
unkinben