From 7ea9e1c9110bd2e4e7697e470d7c47ce3e2cd352 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 8 Oct 2026 19:12:45 +0200 Subject: [PATCH] Add RAPPS-WP-0016: Forgejo sign-in through NetKingdom ORGREF-WP-0002-T05; founder-approved 2026-10-08. Break-glass first, no visibility change, depends on key-cape KEY-WP-0038. Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 5457@bnt-lap001 Assistant-Session: 792bf84a-3783-4f5d-a811-cded61dd2012 --- .../RAPPS-WP-0016-forgejo-netkingdom-login.md | 132 ++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md diff --git a/workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md b/workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md new file mode 100644 index 0000000..65f2cd8 --- /dev/null +++ b/workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md @@ -0,0 +1,132 @@ +--- +id: RAPPS-WP-0016 +type: workplan +title: "Forgejo sign-in through NetKingdom, before the forge closes" +domain: infotech +repo: railiance-apps +status: ready +flavor: implementation +owner: claude-code +topic_slug: railiance +created: "2026-10-08" +updated: "2026-10-08" +depends_on: + - KEY-WP-0038 +related_repos: + - prj-forgejo-org-refactor + - key-cape + - railiance-platform +--- + +# RAPPS-WP-0016 - Forgejo sign-in through NetKingdom, before the forge closes + +## Why + +`forgejo.coulomb.social` is closing: private by default, no anonymous access +(prj-forgejo-org-refactor ORGREF-WP-0002, decision +`decisions/forge-visibility-policy.md`). The founder's condition is that sign-in +runs through NetKingdom first. railiance-apps owns the Forgejo Helm release +(`docs/forgejo-on-railiance01.md`: S5 Helm release, ingress, operator Makefile), +so the Forgejo side lands here. This plan is ORGREF-WP-0002-T05. The NetKingdom +side is key-cape `KEY-WP-0038`. + +## Boundaries + +- **Founder guardrail:** tighten gradually; never lock anyone out; never risk + assets; never reach a state that is hard to repair. Every step keeps the + current sign-in path working until the new one is proven. +- **No visibility change** in this plan. Repositories, packages and + `REQUIRE_SIGNIN_VIEW` are ORGREF-WP-0002-T08. +- **Configuration in git.** The authentication source is declared in + `helm/forgejo-values.yaml` (`gitea.oauth`), with its secret drawn from an + ExternalSecret over OpenBao. No click-ops, and no secret value in git. +- Open registration is already disabled (`service.DISABLE_REGISTRATION: true`). + This plan keeps it that way. + +## Tasks + +```task +id: RAPPS-WP-0016-T01 +status: todo +priority: high +``` + +### T01 — Make the local administrator a sealed break-glass + +Before anything about sign-in changes: confirm the local administrator account +works, keep its credential only in OpenBao, and document recovery (who, how, +where it is logged) in `docs/forgejo-on-railiance01.md`. Verify one break-glass +sign-in and record it without the credential. + +Acceptance: a recorded break-glass sign-in, with the recovery path written down. +This is the "never lock ourselves out" floor for every later step. + +```task +id: RAPPS-WP-0016-T02 +status: wait +depends_on: [RAPPS-WP-0016-T01, KEY-WP-0038-T02] +blocking_reason: "Needs break-glass in place and the NetKingdom client registered with its secret in custody." +priority: high +``` + +### T02 — Add the NetKingdom authentication source + +- an ExternalSecret delivering the `forgejo` client secret from OpenBao (path + from KEY-WP-0038-T02) to a Secret in the `forgejo` namespace +- `gitea.oauth`: name `netkingdom` (must match the redirect URI registered in + key-cape), provider `openidConnect`, auto-discovery from + `https://kc.coulomb.social/.well-known/openid-configuration`, scopes + `openid profile email groups`, group-claim name `groups` +- `oauth2_client` settings: no automatic account creation for unknown subjects; + account linking to existing local accounts by username after a successful + local sign-in (so the founder and agent accounts keep their history) +- Helm upgrade with the previous revision noted for rollback + +Local password sign-in stays enabled. + +Acceptance: the "Sign in with netkingdom" option appears. Local sign-in still +works. Rollback is one `helm rollback` to the noted revision. + +```task +id: RAPPS-WP-0016-T03 +status: wait +depends_on: [RAPPS-WP-0016-T02] +blocking_reason: "Linking and team mapping follow a working authentication source." +priority: high +``` + +### T03 — Link accounts and map groups to teams + +- The founder links their account through NetKingdom (MFA), then signs in again + through NetKingdom only and sees the same repositories, organisations and + admin rights. +- Map NetKingdom groups (names agreed in KEY-WP-0038-T01) to organisation teams: + owners and readers at least. Create the read-only teams that + ORGREF-WP-0002-T06 consumers will use. +- Apply KEY-WP-0038-T03's decision on agents and services: NetKingdom sign-in, or + scoped tokens bound to service identities. + +Acceptance: founder and one agent work through NetKingdom; group-to-team mapping +verified by adding and removing one test membership; break-glass still works. + +```task +id: RAPPS-WP-0016-T04 +status: wait +depends_on: [RAPPS-WP-0016-T03] +needs_human: true +blocking_reason: "Restricting local password sign-in is a founder decision once NetKingdom sign-in is proven." +priority: medium +``` + +### T04 — Decide on local password sign-in + +Once NetKingdom sign-in has been used for a while without problems, the founder +decides whether local password sign-in is turned off for everyone except +break-glass. This is not required to close the forge; it is the next tightening +step, taken separately. + +## Also in scope: stale node credential + +The k3s `registries.yaml` on railiance01 still holds a login for the frozen Gitea +host `92.205.130.254` (ORGREF-WP-0002-T02). Coordinate its removal with the node +owner when ORGREF-WP-0002-T06 adds the forge registry login, in the same change.