NK-WP-0041-T02: rollback confirmed; 4.39 root cause and staged fix path
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:
parent
329a03d149
commit
ee8f9c8a67
1 changed files with 28 additions and 1 deletions
|
|
@ -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.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue