feat(wiki): gate wiki sign-in to Wiki Readers and enable encyclopedia planning #1435

2026-10-25T14:14:38Z

claude-bot commented

2026-10-25 14:14:38 +00:00

This is the homelab side of the house encyclopedia (konairius/Wiki#17, merged).

Authentik: a new group Wiki Readers, declared without users:, and a policy binding of that group to the OIDC application wiki. Only members can sign in to wiki.renner.uno, and only members see private encyclopedia content. The binding has the same shape as the existing hermes and synology bindings.
wiki deployment: Wiki__Encyclopedia__Enabled=true and Wiki__Encyclopedia__MaxArticles=0. The first nightly run (06:00 Europe/Berlin) makes one planning call and commits only articles/_plan.json and articles/_state.json to konairius/notes; it writes no articles. A follow-up PR sets PilotSlugs for the three pilot articles once the plan's slugs are known.
Exposure: wiki.renner.uno stays LAN- and NetBird-only, with neither the dns.renner.uno/public nor the netbird.renner.uno/public label.

⚠️ Before merging

In Authentik, create the group Wiki Readers by hand (Directory → Groups → Create; exactly that name) and add your own account, plus anyone else who should see private content. The blueprint matches the group by name and adopts it, keeping its members, the same way as Unifi Users. Without this, nobody can sign in to the wiki once the blueprint applies.
The policy binding is checked only at sign-in. Anyone already signed in to the wiki keeps their session, and with it private /house content, until the session expires.

Machine clients (wiki-index BasicAuth and API keys) are not affected by the binding, because they don't use the OIDC flow.

Checks

kubectl kustomize kubernetes/apps/authentik and kubectl kustomize kubernetes/apps/wiki both render. That is what CI's kustomize-build step runs.
After merge: the blueprint applies cleanly; a non-member is denied at the wiki login; the 06:00 run plans and writes 0 articles.

🤖 Generated with Claude Code

This is the homelab side of the house encyclopedia (konairius/Wiki#17, merged). - **Authentik:** a new group `Wiki Readers`, declared without `users:`, and a policy binding of that group to the OIDC application `wiki`. Only members can sign in to wiki.renner.uno, and only members see private encyclopedia content. The binding has the same shape as the existing hermes and synology bindings. - **wiki deployment:** `Wiki__Encyclopedia__Enabled=true` and `Wiki__Encyclopedia__MaxArticles=0`. The first nightly run (06:00 Europe/Berlin) makes one planning call and commits only `articles/_plan.json` and `articles/_state.json` to `konairius/notes`; it writes no articles. A follow-up PR sets `PilotSlugs` for the three pilot articles once the plan's slugs are known. - **Exposure:** wiki.renner.uno stays LAN- and NetBird-only, with neither the `dns.renner.uno/public` nor the `netbird.renner.uno/public` label. ## ⚠️ Before merging 1. **In Authentik, create the group `Wiki Readers` by hand** (Directory → Groups → Create; exactly that name) **and add your own account**, plus anyone else who should see private content. The blueprint matches the group by name and adopts it, keeping its members, the same way as `Unifi Users`. Without this, nobody can sign in to the wiki once the blueprint applies. 2. The policy binding is checked only at sign-in. Anyone already signed in to the wiki keeps their session, and with it private `/house` content, until the session expires. Machine clients (wiki-index BasicAuth and API keys) are not affected by the binding, because they don't use the OIDC flow. ## Checks - `kubectl kustomize kubernetes/apps/authentik` and `kubectl kustomize kubernetes/apps/wiki` both render. That is what CI's `kustomize-build` step runs. - After merge: the blueprint applies cleanly; a non-member is denied at the wiki login; the 06:00 run plans and writes 0 articles. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-10-25 14:14:38 +00:00

feat(wiki): gate wiki sign-in to Wiki Readers and enable encyclopedia planning

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

aca39a5a8f

Only members of the new Authentik group Wiki Readers may sign in to the wiki
OIDC application; membership is managed in Authentik, so the owner must be
added before merge. Encyclopedia is enabled with MaxArticles=0 so the first
nightly run only plans.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review-bot reviewed

2026-10-25 14:16:36 +00:00

review-bot left a comment

🤖 Automated review — model claude-opus-5-5, commit aca39a5a8f4114f818dab645ae4f5057db78f55f.

Automated review by the review-bot: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review.

Summary

This PR adds a Wiki Readers Authentik group and binds it to the wiki OIDC application, so only members can sign in. It also turns on the encyclopedia in planning-only mode. The base is the tip of main (c8483b3), the PR is mergeable, and nothing on main or in an open PR replaces it. The blueprint entries match the existing hermes and matrix pattern. I checked MaxArticles=0 against konairius/Wiki#17: it means no articles get written, not "unlimited". I found no blocking issues.

⚪ Unverified

Existing sessions keep working. Authentik checks the policy binding only at authorize time. Anyone signed in to the wiki now who is not added to Wiki Readers keeps their cookie session, and with it private /house content, until that session expires. Private content is gated only by IsHuman (OIDC sign-in, HouseEndpoints.cs in Wiki#17), not by a group claim. I did not read the wiki's cookie lifetime, so I don't know how long that window is.
Planning still writes to konairius/notes. In Wiki#17, EncyclopediaReconciler.InScope runs plan.Articles.Take(0), so no articles are written. A successful plan still commits articles/_plan.json and articles/_state.json to konairius/notes, and spends one planning call (PlanMaxTokens defaults to 32000). "Writes no articles" in the PR body is accurate, but the run is not read-only. The wiki-gitea token is already write:repository (externalsecrets.yaml). I did not check whether other consumers of the notes repo are fine with a new articles/ directory.

🟡 Suggestions

The pre-merge step can't be done as written (kubernetes/apps/authentik/blueprints-configmap.yaml:1039-1045, and the PR body's "Before merging" step 1). This blueprint creates Wiki Readers, so before merge there is no such group under Directory → Groups to add yourself to. Two ways to fix the instructions:
- Create the group by hand first, with exactly the name Wiki Readers, and add your account. The blueprint matches groups by name and will adopt it, keeping the members, as the comment at lines 577-581 says.
- Or say plainly that wiki sign-in fails for everyone between the blueprint applying and someone adding members.
The other option is a users: list with k.renner, as Matrix (lines 917-918) and Hermes (lines 984-985) have. That would make git own the membership, which goes against the stated "members are managed in Authentik" choice, so the instruction fix is probably the better one.

Tests

Only manifest and blueprint changes. The repo's check is the CI kustomize-build step, which the PR says passes for both kustomizations. Nothing in CI parses the embedded blueprint string, so after merge it's worth checking that:

the blueprint instance applies cleanly in Authentik;
a non-member gets denied at https://auth.renner.uno/application/o/wiki/;
the 06:00 run logs a plan with 0 written.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `claude-opus-5-5`, commit `aca39a5a8f4114f818dab645ae4f5057db78f55f`. > Automated review by the `review-bot`: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review. --- ## Summary This PR adds a `Wiki Readers` Authentik group and binds it to the `wiki` OIDC application, so only members can sign in. It also turns on the encyclopedia in planning-only mode. The base is the tip of `main` (c8483b3), the PR is mergeable, and nothing on `main` or in an open PR replaces it. The blueprint entries match the existing hermes and matrix pattern. I checked `MaxArticles=0` against konairius/Wiki#17: it means no articles get written, not "unlimited". I found no blocking issues. ## ⚪ Unverified - **Existing sessions keep working.** Authentik checks the policy binding only at authorize time. Anyone signed in to the wiki now who is not added to `Wiki Readers` keeps their cookie session, and with it private `/house` content, until that session expires. Private content is gated only by `IsHuman` (OIDC sign-in, `HouseEndpoints.cs` in Wiki#17), not by a group claim. I did not read the wiki's cookie lifetime, so I don't know how long that window is. - **Planning still writes to `konairius/notes`.** In Wiki#17, `EncyclopediaReconciler.InScope` runs `plan.Articles.Take(0)`, so no articles are written. A successful plan still commits `articles/_plan.json` and `articles/_state.json` to `konairius/notes`, and spends one planning call (`PlanMaxTokens` defaults to 32000). "Writes no articles" in the PR body is accurate, but the run is not read-only. The `wiki-gitea` token is already `write:repository` (`externalsecrets.yaml`). I did not check whether other consumers of the notes repo are fine with a new `articles/` directory. ## 🟡 Suggestions - **The pre-merge step can't be done as written** (`kubernetes/apps/authentik/blueprints-configmap.yaml:1039-1045`, and the PR body's "Before merging" step 1). This blueprint creates `Wiki Readers`, so before merge there is no such group under Directory → Groups to add yourself to. Two ways to fix the instructions: - Create the group by hand first, with exactly the name `Wiki Readers`, and add your account. The blueprint matches groups by `name` and will adopt it, keeping the members, as the comment at lines 577-581 says. - Or say plainly that wiki sign-in fails for everyone between the blueprint applying and someone adding members. The other option is a `users:` list with `k.renner`, as Matrix (lines 917-918) and Hermes (lines 984-985) have. That would make git own the membership, which goes against the stated "members are managed in Authentik" choice, so the instruction fix is probably the better one. ## Tests Only manifest and blueprint changes. The repo's check is the CI `kustomize-build` step, which the PR says passes for both kustomizations. Nothing in CI parses the embedded blueprint string, so after merge it's worth checking that: - the blueprint instance applies cleanly in Authentik; - a non-member gets denied at `https://auth.renner.uno/application/o/wiki/`; - the 06:00 run logs a plan with `0 written`. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

k.renner merged commit 6fa10a7744 into main

2026-10-25 14:51:08 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1435