jakman85andClaude Opus 5
ea0c0632d2
Reported: "crafty does not sign in after signing into keycloak, and there is
no way to set the service up without credentials."
MEASURED, not inferred. The sidecar log settles which layer refused:
GET / -> 302 to Keycloak
[AuthSuccess] ... groups:[platform-admins] <- oauth2-proxy is FINE
GET /oauth2/callback -> 302
GET /login?next=/panel/dashboard -> 200 <- Crafty's OWN login page
POST /api/v2/auth/login/ -> 401 <- Crafty refused
So the Keycloak gate was never broken. Crafty 4 has no OIDC and cannot consume
the sidecar's identity headers, so it shows its own local login to an already
authenticated user. That second factor is intended. What was NOT intended is
that nothing documented where its password comes from, which is exactly why
setup was impossible: Crafty generates it ONCE on first boot (users table
empty -> DatabaseBuilder.default_settings()) into /crafty/app/config/
default-creds.txt, mode 0600, on the PVC's `config` subPath. Never in git;
a fresh PVC generates a new one. The README asserted the double login was
"expected, not a bug" and then left the reader with no way forward.
Verified in-cluster that the existing credential is still usable, so the
service can be set up without touching the DB: users.last_update equals
users.created for `admin` (09/05/2026, 08:10:04), i.e. the password has never
been changed, and admin's last_login is 09/14 from 127.0.0.1 -- the API login
that created the "homelab" server. default-creds.txt is therefore live.
ALSO FIXED -- a real, separate defect found while proving the above, which
produces the reported symptom intermittently and would have been blamed on
Keycloak forever: this sidecar and the SHARED forward-auth oauth2-proxy both
emitted oauth2-proxy's DEFAULT cookie names (_oauth2_proxy,
_oauth2_proxy_csrf) scoped to .home.keithjackson.dev, while holding DIFFERENT
cookie-secrets (compared the two live Secrets: they differ, so neither can
decrypt the other's cookie). One cookie pair, two proxies: whichever
authenticated last clobbered the other's session; the loser logged "No valid
authentication in request", bounced to Keycloak, and -- SSO session still live
-- was redirected straight back, clobbering it again. Fixed on this side only
(renaming the shared proxy's cookie would sign out every other gated app):
a unique --cookie-name plus a host-scoped --cookie-domain, since a per-app
reverse proxy has no reason to broadcast its session zone-wide.
--whitelist-domain stays zone-wide: it governs redirect targets, not cookies.
Two traps measured rather than assumed, both now documented:
- The 3-strikes cooldown CANNOT fire behind this sidecar. Crafty records
attempts under get_remote_ip() (honours X-Forwarded-For -- the live
tracker key is the chain "192.168.2.132, 10.0.0.123") but checks the
cooldown under request.remote_ip, which is always 127.0.0.1 here. The
halves key differently, so get_recent_attempts() always reads empty.
Good (no lockout risk) and bad (that throttle is not a control we have).
- Crafty's `set_passwd` console command is unreachable in k8s: it calls
getpass.getpass() and needs a TTY; the container runs `main.py -d -i`.
Recovery has to go through the DB, and argon2 is installed ONLY in
/crafty/.venv/bin/python -- the system python3 lacks it.
Deliberately NOT done: an initContainer seeding default.json from a SOPS
Secret to make a rebuilt Crafty's password deterministic. Crafty does support
that hook (find_default_password reads app/config/default.json, min 8 chars),
but the image entrypoint pulls its default config ONLY when app/config is
EMPTY -- so writing a file there pre-boot suppresses the whole config
bootstrap. Buying reproducibility means co-owning image-internal bootstrap
logic that a 4.11 bump could silently change, to replace a one-command
retrieval. Recorded in DECISIONS-LOG as considered and rejected.
New runbook runbooks/crafty-admin-credential.md: tell the two auth layers
apart from the sidecar log, retrieve and rotate the bootstrap credential,
and reset a lost one via argon2 -- generating the password in-pod into a 0600
file rather than passing it in, because dev.sh does not forward stdin (a
`kubectl exec -i` through it hangs; verified). Registered in the configMapGenerator
so the URL actually resolves, not just the file exists.
Gate: toolbox ./ci/gate.sh -- lint/l0/render-golden/l1 green, spec-immutability
green. rc 3 overall: gitea-settings SKIPPED (no SETTINGS_API_TOKEN) and L2/L3
NOT RUN (CLUSTER_AVAILABLE unset). No runtime browser round-trip performed --
the sign-in fix is UNVERIFIED end-to-end and needs the human test in the README.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
162 lines
11 KiB
Markdown
162 lines
11 KiB
Markdown
# Alert runbooks — home-network-k3s prod
|
||
|
||
This is the index page served at `https://home.keithjackson.dev/runbooks/`.
|
||
|
||
Every alert rule in this platform carries an annotation of the form
|
||
|
||
runbook_url: "https://${BASE_DOMAIN}/runbooks/<name>"
|
||
|
||
46 of them, over 35 names. Until this directory existed, that path returned **HTTP 404** on the
|
||
live cluster: every alert that reached a human handed them a dead link at the exact moment they needed
|
||
help. These pages are what makes the link resolve.
|
||
|
||
## How to run the commands in these runbooks
|
||
|
||
`kubectl` does not work on the operator workstation. The toolchain lives only in the pinned dev
|
||
container, and the host's `k3s-oidc` context hangs on a browser prompt once its token expires — that hang
|
||
is not the cluster being down.
|
||
|
||
infra/devcontainer/dev.sh run bash -c 'kubectl --context k3s-prod get nodes'
|
||
|
||
Always pass `--context k3s-prod`. `dev.sh` merges BOTH clusters into one kubeconfig and picks a
|
||
current-context per invocation, and **that default has already changed once** — k3s-dev until dev was
|
||
decommissioned on 2026-09-13, k3s-prod now. A command that names its context still means the same thing
|
||
next month; one that relies on the default does not, and the failure is silent. `CLUSTER=prod
|
||
infra/devcontainer/dev.sh run kubectl ...` selects it explicitly, and every invocation prints a banner
|
||
naming the cluster — read it. Do not run two `dev.sh` invocations at once; they share one container.
|
||
|
||
**Use fully-qualified resource names, always.** Three CRDs on this cluster register the kind `Backup` —
|
||
`longhorn.io/v1beta2`, `postgresql.cnpg.io/v1`, `velero.io/v1` — and the bare short name resolves to
|
||
Longhorn's, which holds zero objects. `kubectl get backup -A` therefore prints **"No resources found"** on
|
||
a cluster holding 6 Velero and 27 CNPG backups (verified on prod 2026-09-13). Acting on that false
|
||
negative is how a CLI quirk becomes real data loss. Write `backups.velero.io`,
|
||
`backups.postgresql.cnpg.io`, `clusters.postgresql.cnpg.io`, `settings.longhorn.io`,
|
||
`volumes.longhorn.io`, `nodes.longhorn.io`.
|
||
|
||
Merging a PR into `main` **is** the deploy; there is no other apply step. `main` is protected, so a
|
||
direct push is rejected — durable changes go through a branch, a PR, and a green gate.
|
||
|
||
## Alerts you should not trust the silence of (measured 2026-09-13)
|
||
|
||
The Longhorn and cert-manager scrapes were ENABLED on 2026-09-13, so the Longhorn row below is no
|
||
longer inert — and re-keying the two robustness rules the same day fixed a SECOND inertness the
|
||
scrape had left in place (the metric is one-hot over a `state` label, not a 0–3 enum). Take the
|
||
Longhorn row as history; the rest of this table still holds, and Flux-controller and Hubble/Cilium
|
||
rule groups still evaluate against nothing and **cannot fire**:
|
||
|
||
| Missing scrape job | Inert alerts |
|
||
|---|---|
|
||
| Longhorn | `LonghornVolumeDegraded`, `LonghornVolumeFaulted`, `LonghornDiskAllocationHigh`, `LonghornDiskUnschedulable` |
|
||
| cert-manager | `CertificateExpiringSoon`, `CertificateExpiryImminent`, `CertificateNotReady` |
|
||
| Flux (`gotk_*`) | `FluxReconciliationFailure`, `FluxResourceSuspended`, `ImageUpdateAutomationFailing`, `ImagePolicyStalled`, `UpdateHealthGateFailed` |
|
||
| Hubble (`hubble_drop_total`) | `HubbleDeniedFlowSpike` |
|
||
| etcd (`kubeEtcd` disabled for k3s, deliberately) | no etcd fsync alerting exists at all |
|
||
|
||
Each affected runbook says so on its own page and gives the by-hand equivalent. See `targets-down`.
|
||
|
||
## The runbooks
|
||
|
||
### Nodes
|
||
- **`node-down`** — a node's node-exporter is unscrapable; the node may be gone, or its kubelet may have
|
||
stopped posting status while the host stays up (the 2026-09-07 shape).
|
||
- **`node-io`** — disk I/O pressure/starvation. The etcd WAL shares a partition with Longhorn replicas;
|
||
this is the alert that would have called the 2026-09-07 outage and did not exist at the time.
|
||
- **`node-memory`** — memory pressure. Includes why `SwapTotal == 0` is not evidence swap is off.
|
||
- **`node-disk`** — a node filesystem filling up. `/data` is the one that matters.
|
||
- **`node-cpu`** — CPU PSI and run-queue depth, and how to tell CPU contention from I/O contention.
|
||
|
||
### Storage
|
||
- **`longhorn-degraded`** — a volume has lost redundancy. Normal after any reboot, and the rebuild is the
|
||
expensive part. Freeze/thaw commands here.
|
||
- **`longhorn-faulted`** — no usable replica. Data at risk; stop before anything destructive.
|
||
- **`longhorn-capacity`** — a node's Longhorn disk running out of room for replicas (allocation, not PVC fill; for PVC fill see `pvc-capacity` / `monitoring-capacity`).
|
||
- **`pvc-capacity`** — PVC filling up / almost full / predicted to fill. These rules work.
|
||
- **`monitoring-capacity`** — Prometheus or Loki running out of disk; don't let the monitor blind itself.
|
||
|
||
### GitOps and updates
|
||
- **`flux-reconcile`** — a Flux resource stuck at Ready=False. Which tier decides the blast radius.
|
||
- **`flux-suspended`** — reconciliation turned off and forgotten. Drift becomes silent.
|
||
- **`update-rollback`** — a HelmRelease failed its health gate and is rolling back.
|
||
- **`image-automation`** — the git write-back engine is failing (feature is disabled here).
|
||
- **`image-policy-stalled`** — an ImagePolicy/ImageRepository cannot resolve a tag.
|
||
|
||
### Certificates
|
||
- **`cert-issuance`** — ACME issuance failing. The DNS-01 self-check is the usual cause.
|
||
- **`cert-expiry`** — a certificate is expiring. Almost always a late symptom of `cert-issuance`.
|
||
|
||
### Networking
|
||
- **`vpn-down`** — the egress VPN tunnel. Explains what the kill-switch actually does, and the silent
|
||
egress-gateway staleness this alert cannot see — which now has its own alerts and page below.
|
||
- **`vpn-egress-stale`** — the tunnel is UP but `egress-class=vpn` pods have no egress: Cilium's cached
|
||
ifindex outlived a reconnect. Also covers the watchdog for that rule going inert.
|
||
- **`denied-flows`** — policy-denied flow spike. The Cilium hairpin/identity regression class.
|
||
|
||
### Backups and DR
|
||
- **`backup-failure`** — a Velero backup failed. The R2 object-tagging incompatibility is documented here.
|
||
- **`backup-partial`** — a Velero backup completed with partial failures, and which skips are deliberate.
|
||
- **`backup-missed`** — no successful Velero backup in 24h.
|
||
- **`cnpg-archiving`** — WAL archiving stuck / no recoverability point. **An availability incident, not
|
||
just a backup one.**
|
||
- **`cnpg-backup-missed`** — no recent CNPG base backup. Velero does not cover these databases.
|
||
- **`cnpg-wal-growth`** — `pg_wal` not being recycled. Never delete WAL by hand.
|
||
- **`cnpg-exporter`** — the CNPG SQL exporter erroring: a blind spot that looks exactly like health.
|
||
- **`cnpg-primary-spread`** — two or more CNPG primaries on one node. Blast radius, not an outage,
|
||
and the rebalance costs ~9s of writes per database — one cluster at a time.
|
||
|
||
### Identity
|
||
- **`keycloak-down`** — the IdP is down. Blast radius, and the break-glass path that still works.
|
||
- **`keycloak-db`** — Keycloak's CloudNativePG database is unavailable.
|
||
- **`keycloak-client-secrets`** — the client/URL reconciler failing or silent. The 2026-09-06 lockout that
|
||
every green signal missed.
|
||
|
||
### Operator procedures (no alert links here)
|
||
- **`plex-claim`** — claiming the Plex Media Server. **Claimed 2026-09-29**; the page now only
|
||
applies after a `/config` wipe. The claim token is short-lived — read the countdown on
|
||
plex.tv/claim — so it is a timed sequence, scripted as `infra/plex/claim-ship.sh`:
|
||
token → `sops` → PR → gate → merge → **forced** `flux reconcile` → pod roll (~2m45s measured).
|
||
Includes why a changed Secret does not restart anything, and why an expired token is harmless.
|
||
- **`crafty-admin-credential`** — you signed into Keycloak and Crafty *still* asks for a password.
|
||
Expected: Crafty 4 has no OIDC, so its own local login sits behind the oauth2-proxy gate as a second
|
||
factor. The page tells the two layers apart from the sidecar log, and explains that the bootstrap
|
||
password exists **only** on the PVC (`default-creds.txt`, generated once on first boot, never in git).
|
||
Includes the argon2 reset for a lost password, why the 3-strikes lockout cannot fire behind the
|
||
sidecar, and why deleting `crafty.sqlite` to force a new password destroys every server definition.
|
||
|
||
### Virtualisation
|
||
- **`kubevirt-control-plane`** — VM lifecycle operations will fail; running VMs keep running.
|
||
- **`kubevirt-launch-failed`** — a VMI reached the Failed phase. The three k3s-specific launch traps.
|
||
- **`kubevirt-crashloop`** — a virt-launcher pod restarting repeatedly.
|
||
- **`cdi-import-stuck`** — a DataVolume import not progressing. Check node I/O before restarting it.
|
||
|
||
## Editing a runbook
|
||
|
||
Each page is `runbooks/<name>.md` in the `home-network-k3s-impl` repo. Edit it, push to `main`, and Flux
|
||
re-renders the ConfigMap and rolls the two-replica server; kustomize's content hash on the generated
|
||
ConfigMap name is what triggers the roll.
|
||
|
||
Adding a **new** alert with a `runbook_url` requires the matching `runbooks/<name>.md` **and** its
|
||
`<name>=<name>.md` entry in `runbooks/kustomization.yaml`. Both are enforced by
|
||
`conformance/tests/l0-static/alert-runbooks-resolvable`, which runs unconditionally in the merge gate —
|
||
"the file exists in git" and "the URL resolves in the cluster" are different claims, and it checks both.
|
||
|
||
Every page must carry the four operator sections (*What this means here*, *First commands*, *Likely
|
||
causes, most likely first*, *When to escalate or stop*), mention `dev.sh`, and pass `--context k3s-prod`.
|
||
The check enforces that too, because a stub that makes the link resolve while helping nobody is worse than
|
||
the 404 it replaced — it looks fixed.
|
||
|
||
## Why this route has no login
|
||
|
||
Deliberately public. The UIs that declare forward-auth (pihole, jackett, qbittorrent, radarr, sonarr)
|
||
really are closed: enforcement is per-pod, each one's HTTPRoute targeting its oauth2-proxy sidecar on
|
||
:4180 rather than the app port. If
|
||
these pages did too, `keycloak-down` would be unreadable exactly when Keycloak is down,
|
||
`keycloak-db` unreadable when its database is down, and `keycloak-client-secrets` unreadable during the
|
||
precise failure that broke all 12 OIDC clients on 2026-09-06 behind an entirely green cluster. An
|
||
operator who cannot log in is this route's primary reader. The content is operational procedure — metric
|
||
names, thresholds, kubectl invocations, topology — and no secrets. See
|
||
`runbooks/serving/httproute.yaml` for the full reasoning, including how forward-auth is actually
|
||
enforced here and the instruction to leave this route **out** of any Gateway-level ext-authz attachment
|
||
if one is ever introduced.
|
||
|
||
The running narrative of real incidents on this cluster is `DECISIONS-LOG.md`.
|