recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

decisions(2): record operator SSO-provider policy — keycloak DEFAULT for all recipe OIDC; authentik NOT a Phase-2 DONE gate (enroll only if a recipe REQUIRES it); cryptpad OIDC under keycloak; narrow DEFERRED #9 authentik re-entry trigger

Browse Source
This commit is contained in:
autonomic-bot
2026-05-29 09:09:38 +01:00
parent 779fb8917c
commit 1537a928d5
2 changed files with 24 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
machine-docs/DECISIONS.md
View File

@ -706,3 +706,21 @@ DEFERRED.md 2026-05-29). Until then, heavy recipes are verified via their maxima
(install+backup+restore+custom) with the upgrade tier flagged as a genuine env-level (disk) blocker
per plan §7.1 (Adversary sign-off required). The cleanup runbook for an over-full host: `pkill -f
run_recipe_ci.py`; `docker stack rm <leftover>`; remove its volumes+secrets; `docker image prune -f`.
## SSO-provider policy (operator, 2026-05-29) — keycloak is the DEFAULT; authentik is NOT a DONE gate
Standing policy for all Phase-2 (and later) recipe OIDC/SSO testing:
- **keycloak is the default SSO provider.** Default ALL recipe OIDC tests to keycloak (live-warm WC1).
- **Do NOT test authentik↔keycloak integration**, and do NOT enroll authentik merely to "prove
pluggability" / second-provider coverage. **Phase-2 DONE is NOT gated on authentik.**
- Enroll authentik + add `setup_authentik_realm` (the provider-pluggable backend in
`runner/harness/sso.py`) **ONLY if a recipe genuinely REQUIRES authentik** (cannot work under
keycloak). If it works with keycloak, use keycloak.
- **cryptpad:** its recipe-maintainer upstream SSO test uses authentik, but cc-ci tests cryptpad's OIDC
under **keycloak** (equally valid). Same for any recipe whose upstream happens to use authentik but
functions fine under keycloak.
- The OIDC FLOW primitives (`oidc_password_grant`, `assert_discovery_endpoint`) are already
provider-agnostic; only realm/client SETUP is provider-specific, and we only need the keycloak setup
(`setup_keycloak_realm`) unless/until a recipe forces authentik.
Consequences: DEFERRED #9 (authentik enrollment) re-entry trigger narrowed to "a recipe requires
authentik"; F2-7 (authentik backend) is not a DONE blocker. plan-sso-dep-testing.md §6 updated by the
orchestrator to match.

10
machine-docs/DEFERRED.md
View File

@ -150,10 +150,12 @@ before the build is called done) — but does **not** force closure.
recipe-maintainer SSO test uses authentik but that parity port is already deferred above). The
SSO harness's OIDC FLOW primitives (`oidc_password_grant`, `assert_discovery_endpoint`) are
already provider-agnostic; only `setup_keycloak_realm` is keycloak-specific.
- **Re-entry trigger:** When Q3.4 cryptpad's deferred `oidc_login.py` parity is lifted (cryptpad's
upstream test uses authentik), OR when an additional Q4 recipe enrolls with `DEPS = ["authentik"]`,
OR Phase-2 DONE review (operator may insist on second-provider coverage proving the harness IS
pluggable, not just claimed).
- **Re-entry trigger (NARROWED per operator SSO policy 2026-05-29):** ONLY when a recipe **genuinely
REQUIRES authentik** (cannot work under keycloak). Dropped the former triggers — cryptpad's OIDC is
now tested under **keycloak** (its upstream uses authentik but keycloak is equally valid), and
**Phase-2 DONE is explicitly NOT gated on authentik** (no "prove pluggability"/second-provider/
DONE-review trigger). keycloak is the default SSO provider for all recipe OIDC tests. See
DECISIONS.md "SSO-provider policy".
- **Linked IDEA:** —
### 2026-05-29 — heavy-recipe upgrade tier needs more host disk (28GB too small) — CLOSED @2026-05-29