Jellyfin moves to Authentik SSO via jellyfin-plugin-sso (OIDC), keeping
native clients on Jellyfin local/API auth. Adds the oauth2 provider and
application for jellyfin.k8s.syd1.au.unkin.net plus the akP permission
groups gating access, wired into the standard-user and global-admin
roles per the two-tier RBAC model.
- Adds providers_oauth2/jellyfin.yaml: confidential client, secret read
from kv/kubernetes/namespace/jellyfin/default/oauth-credentials,
redirect URIs for the SSO plugin callback paths
- Adds akP-jellyfin-admin and akP-jellyfin-user bound to the app
- Nests akP-jellyfin-user under akR-standard-user and
akP-jellyfin-admin under akR-global-admin
Add the Authentik OIDC application that fronts the arrproxy media front door
at arrstack.unkin.net, plus the per-app entitlement groups arrproxy reads from
the user's groups claim to decide which backends (sonarr/radarr/prowlarr) a
user may reach.
- config/providers_oauth2/arrstack.yaml: confidential oauth2 client
client_id=arrstack, litellm-style auth/invalidation flows, client_secret
from Vault kv kubernetes/namespace/arrstack/default/oauth-credentials,
openid/email/profile scopes, redirect https://arrstack.unkin.net/oauth2/callback,
launch https://arrstack.unkin.net/. The module always attaches the estate's
hierarchical ak_groups scope mapping, so the front door emits the groups claim.
- config/permissions/akP-arrstack-user.yaml: front-door gate (application: arrstack).
- config/permissions/akP-arrstack-{sonarr,radarr,prowlarr}.yaml: per-app
entitlements, unbound (no application) so they only surface in the ak_groups
claim for arrproxy to authorize backends.
- config/roles/akR-arrstack-user.yaml: full media role nesting all four.
- akR-global-admin: also nests the arrstack front door + all per-app perms.
Bring LiteLLM into the two-tier RBAC and map groups to LiteLLM roles.
- akP-litellm-admin / akP-litellm-user permission groups (bound to the litellm
app for access); added to akR-global-admin / akR-standard-user roles.
- Generic per-provider role_mappings: emit an app role claim computed from
effective (hierarchical) group membership. LiteLLM: emits `litellm_role`
(proxy_admin for akP-litellm-admin, internal_user for akP-litellm-user, else
internal_user_view_only); LiteLLM reads it via GENERIC_USER_ROLE_ATTRIBUTE.
Validated: plan 5 to add, 3 to change; generated role expression renders correctly.
- Permission/role group name now comes from the config filename (the map key),
dropping the redundant `name` field from each YAML and the object types.
- The hierarchical mapping emits an `ak_groups` claim (scope `ak_groups`) instead
of `groups`, so it never collides with the direct-groups the default profile
mapping already emits under `groups` (Authentik overrides same-key claims in an
unpredictable order). Apps request the `ak_groups` scope and read that claim.
unkin-agent
unkin-agent
unkinben