docs: dashboard access is forward-auth + token-paste (OIDC SSO blocked)
Correct the docs I'd written for the (reverted) oauth2-proxy SSO. Reality: apiserver OIDC rejects all Authentik tokens (design §12), so the dashboard uses forward-auth (admits kubernetes-* groups) + per-namespace SA token-paste. Updates authentication.md, multi-tenancy.md, service-catalog, authentik-state, and add-user skill (onboarding now documents the dashboard token). oauth2-proxy + k8s-dashboard OIDC app noted as idle. [ci skip] Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
e4c3fbbbbb
commit
8e44ccaa65
5 changed files with 70 additions and 55 deletions
|
|
@ -18,12 +18,16 @@
|
|||
| wrongmove | OAuth2/OIDC | implicit consent |
|
||||
|
||||
> **Kubernetes Dashboard** (TF-managed in `stacks/k8s-dashboard/authentik.tf`):
|
||||
> confidential client `k8s-dashboard` consumed by oauth2-proxy in front of the
|
||||
> web dashboard. Has a custom scope mapping `k8s-dashboard audience` (scope
|
||||
> `k8s-dashboard-audience`) emitting `aud=[kubernetes,k8s-dashboard]`, plus a
|
||||
> group-access policy restricting login to `kubernetes-admins` /
|
||||
> `kubernetes-power-users` / `kubernetes-namespace-owners`. The apiserver trusts
|
||||
> this app's issuer via the `rbac` stack structured `AuthenticationConfiguration`.
|
||||
> confidential client `k8s-dashboard`, built for seamless dashboard SSO via
|
||||
> oauth2-proxy. **Currently IDLE** — the apiserver rejects all OIDC tokens (see
|
||||
> `docs/plans/2026-06-04-k8s-dashboard-sso-design.md` §12), so the dashboard runs
|
||||
> on forward-auth + token-paste instead and oauth2-proxy is unwired. Kept for a
|
||||
> future SSO retry once apiserver OIDC is fixed.
|
||||
>
|
||||
> **admin-services-restriction** policy (TF-managed in
|
||||
> `stacks/authentik/admin-services-restriction.tf`, adopted 2026-06-04): gates the
|
||||
> 15 admin-only hostnames to `Home Server Admins`, with a carve-out admitting the
|
||||
> `kubernetes-*` RBAC groups to `k8s.viktorbarzin.me` (dashboard login page).
|
||||
|
||||
## Groups (9)
|
||||
| Group | Parent | Superuser | Purpose |
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@
|
|||
## Admin
|
||||
| Service | Description | Stack |
|
||||
|---------|-------------|-------|
|
||||
| k8s-dashboard | Kubernetes dashboard at `k8s.viktorbarzin.me`. Authentik SSO via **oauth2-proxy** (`auth=none`; oauth2-proxy injects the user's OIDC id_token from the `k8s-dashboard` confidential client as Bearer → per-user RBAC at the apiserver). Multi-issuer apiserver auth in `stacks/rbac`. | k8s-dashboard |
|
||||
| k8s-dashboard | Kubernetes dashboard at `k8s.viktorbarzin.me`. **Forward-auth + token-paste** (interim — apiserver OIDC blocked, see `docs/plans/2026-06-04-k8s-dashboard-sso-design.md` §12). Forward-auth admits `kubernetes-*` groups for this host; each namespace-owner pastes a per-namespace SA token (`dashboard-<user>` in their ns, `stacks/rbac/.../dashboard-sa.tf` — ns admin + cluster read-only). Admins use the `kubernetes-dashboard` cluster-admin SA token. oauth2-proxy + `k8s-dashboard` OIDC app built but idle. | k8s-dashboard |
|
||||
| reverse-proxy | Generic reverse proxy | reverse-proxy |
|
||||
| t3code | Multi-user coding-agent GUI at t3.viktorbarzin.me. `auth=required` (Authentik) → DevVM `t3-dispatch` service (`10.0.10.10:3780`, unprivileged user) maps `X-authentik-username` → that user's own `t3-serve@<u>` instance (file perms enforced by uid; wizard→:3773, emo→:3774; unmapped→403) and **auto-injects the t3 session on first visit** (mints via the root `t3-mint` wrapper, scoped sudoers → `/api/auth/bootstrap` `t3_session` cookie). Source of truth `/etc/ttyd-user-map`; `t3-provision-users` reconcile (systemd timer) turns map entries into `t3-serve@<u>` instances + `dispatch.json`. **Add a user:** one line in `/etc/ttyd-user-map` (must already be an OS account + Authentik identity) → reconcile. DevVM artifacts versioned in `infra/scripts/` (`t3-serve@.service`, `t3-provision-users`, `t3-dispatch/`, `t3-mint`, `sudoers-t3-autopair`, `t3-autoupdate.*`); TF (`stacks/t3code`) owns only the ingress + Endpoints→:3780. **t3 binary tracks `nightly`** via `t3-autoupdate` (daily systemd timer; health-check + auto-rollback on a bad build; restarts only idle instances) — so new models (e.g. Opus 4.8) land as t3 ships them. Native app/app.t3.codes unsupported (cross-origin) — deferred until published. Design: `docs/plans/2026-06-01-t3-auto-provision-*`. | t3code |
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue