viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: dashboard now auto-injects per-user SA token (no token-paste)

Browse source 
Update authentication.md, multi-tenancy.md, service-catalog, add-user skill to
reflect the token-injector (X-authentik-username -> SA token -> Bearer). Note the
extra k8s-dashboard apply needed when onboarding a namespace-owner (injector map
regen). [ci skip]

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Viktor Barzin 2026-06-04 08:05:34 +00:00
parent d649f4f287
commit c4bd64f88a
4 changed files with 47 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

36
docs/architecture/authentication.md
View file

@ -122,26 +122,32 @@ The intended model (binds by `email`, see `stacks/rbac/modules/rbac/main.tf`):
`admin` → `cluster-admin`; `power-user` → custom read-mostly ClusterRole;
`namespace-owner` → `admin` RoleBinding in their namespace(s) + cluster read-only.
### Kubernetes Dashboard access (token-paste, interim)
### Kubernetes Dashboard access (auto-injected SA token)
Because OIDC SSO is blocked, the web dashboard at `k8s.viktorbarzin.me` uses:
Because OIDC SSO is blocked, the web dashboard at `k8s.viktorbarzin.me` uses a
**token-injector** instead — users never see the dashboard's token prompt:
1. **Authentik forward-auth** gates *who reaches the login page*
(`admin-services-restriction` policy — admits `Home Server Admins` plus the
`kubernetes-admins` / `kubernetes-power-users` / `kubernetes-namespace-owners`
groups for this host; see `stacks/authentik/admin-services-restriction.tf`).
2. **Token paste**: each namespace-owner has a ServiceAccount
(`dashboard-<user>` in their namespace, `stacks/rbac/modules/rbac/dashboard-sa.tf`)
scoped to `admin` on their namespace(s) + cluster read-only, with a long-lived
token they paste into the Dashboard's "Token" login. The pasted token — not
forward-auth — is the per-namespace security boundary.
Retrieve: `kubectl -n <ns> get secret dashboard-<user>-token -o jsonpath='{.data.token}' | base64 -d`.
Admins use the cluster-admin `kubernetes-dashboard` SA token
(`kubectl create token kubernetes-dashboard -n kubernetes-dashboard`).
1. **Authentik forward-auth** (`auth=required`) gates access AND injects
`X-authentik-username` (the user's email). The `admin-services-restriction`
policy admits `Home Server Admins` plus `kubernetes-admins` /
`kubernetes-power-users` / `kubernetes-namespace-owners` for this host
(`stacks/authentik/admin-services-restriction.tf`).
2. **Token-injector** (`stacks/k8s-dashboard/dashboard_injector.tf`): an nginx
that maps `X-authentik-username` → that user's ServiceAccount token and sets
`Authorization: Bearer` before proxying to kong-proxy, so the dashboard
auto-authenticates. Namespace-owners → `dashboard-<user>` SA (admin on their
namespace + cluster read-only, `stacks/rbac/modules/rbac/dashboard-sa.tf`),
auto-derived from `k8s_users`. Admins → the cluster-admin `kubernetes-dashboard`
SA token (admin identities listed explicitly in `dashboard_injector.tf`, since
their Authentik login email ≠ their `k8s_users` email).
The injected token is the per-namespace security boundary; the map lives in a
**Secret** (namespace-owners' cluster-read covers configmaps, not secrets).
> Manual token (fallback / break-glass): `kubectl -n <ns> get secret dashboard-<user>-token -o jsonpath='{.data.token}' | base64 -d`, or `kubectl create token kubernetes-dashboard -n kubernetes-dashboard` for admin.
The oauth2-proxy + `k8s-dashboard` Authentik OIDC app (built for the
seamless-SSO design) remain deployed but **idle/unwired** pending the
apiserver-OIDC fix; the dashboard ingress is on forward-auth.
apiserver-OIDC fix.
### Authentik Groups

26
docs/architecture/multi-tenancy.md
View file

@ -171,22 +171,20 @@ Each user receives:
```
6. User can now run `kubectl` commands
### Web Dashboard (token-paste)
### Web Dashboard (auto-login, no token paste)
Namespace-owners can manage their namespace from the **Kubernetes Dashboard** at
`https://k8s.viktorbarzin.me`:
Namespace-owners just log into `https://k8s.viktorbarzin.me` with their Authentik
account and land straight in the dashboard scoped to their namespace — **no token
to paste**. A token-injector (`stacks/k8s-dashboard/dashboard_injector.tf`) maps
their Authentik identity (`X-authentik-username`) to their `dashboard-<user>` SA
token (`admin` on their namespace + cluster read-only) and injects it as
`Authorization: Bearer`. Forward-auth admits the `kubernetes-*` groups for this
host (`stacks/authentik/admin-services-restriction.tf`).
1. Log in via Authentik (forward-auth admits the `kubernetes-*` groups for this
host — `stacks/authentik/admin-services-restriction.tf`).
2. On the Dashboard login page, choose **Token** and paste the personal token:
`kubectl -n <namespace> get secret dashboard-<user>-token -o jsonpath='{.data.token}' | base64 -d`
(the `dashboard-<user>` SA is created per namespace-owner in
`stacks/rbac/modules/rbac/dashboard-sa.tf` — `admin` on their namespace(s) +
cluster read-only).
> **Why token-paste, not seamless SSO:** the intended oauth2-proxy SSO is built
> but blocked — the apiserver currently rejects all Authentik OIDC tokens. See
> `docs/architecture/authentication.md` → "Kubernetes API authentication" and
> **Why not seamless OIDC SSO:** the intended oauth2-proxy OIDC path is built but
> blocked — the apiserver rejects all Authentik OIDC tokens. The injector uses SA
> tokens (which the apiserver accepts) keyed off the forward-auth identity. See
> `docs/architecture/authentication.md` and
> `docs/plans/2026-06-04-k8s-dashboard-sso-design.md` §12.
### RBAC Groups