NK-WP-0041-T02: rollback confirmed; 4.39 root cause and staged fix path
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e
This commit is contained in:
tegwick 2026-09-24 01:57:20 +02:00
parent 329a03d149
commit ee8f9c8a67

View file

@ -59,7 +59,7 @@ to a user; note it here if the password manager still misbehaves.
```task ```task
id: NK-WP-0041-T02 id: NK-WP-0041-T02
status: progress status: wait
priority: medium priority: medium
state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25" state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25"
``` ```
@ -145,3 +145,30 @@ The repository now pins the exact 4.38 digest instead of the floating tag.
Separate finding: Authelia's LDAP startup check fails on the first start Separate finding: Authelia's LDAP startup check fails on the first start
after a pod is scheduled, then passes on restart. after a pod is scheduled, then passes on restart.
Operator confirmation after the rollback, 2026-09-24: sign-in as
`bernd.worsch-99` works again. `bernd.worsch+99@gmail.com` still fails on
4.38, as expected.
Root cause of the 4.39 break. KeyCape's `tokenBaseURL` is the in-cluster
`http://authelia.sso.svc.cluster.local:9091` (declared in
`sso-mfa/k8s/keycape/create-secrets.sh`). The token request sets no
forwarded headers (key-cape `adapter.go`), so Authelia sees an `http`
scheme. 4.38 accepts that; 4.39 will not derive an issuer from it.
Path forward. Stage the fix on 4.38 first, then upgrade with only one
variable changing:
- **A (preferred, config only).** Point `tokenBaseURL` at
`https://auth.coulomb.social`, so the call goes through the ingress with
`X-Forwarded-Proto: https`. First check that the KeyCape pod can reach the
public hostname in-cluster (hairpin). Apply through the guarded KeyCape
config lane with unrelated bytes preserved, then prove it with a real
login on 4.38.
- **B (code).** key-cape sends `X-Forwarded-Proto: https` and
`X-Forwarded-Host` on back-channel calls. Whether 4.39 trusts forwarded
headers from a pod is unverified.
Then retry 4.39.28. The acceptance must include a real human sign-in
through KeyCape, and the `+` email sign-in. The task waits on the choice
of A or B, with key-cape consulted.