eho/register-referentie
1
0
Fork 0
Code Issues 10 Pull Requests 2 Actions 1 Packages Projects Releases 1 Wiki Activity

fix(k8s): keep Keycloak's backchannel URLs https behind the labs Caddy (refs #177) #180

Open
not wants to merge 1 commits from fix/keycloak-proxy-headers into main
pull from: fix/keycloak-proxy-headers
merge into: :main
Conversation 0 Commits 1 Files Changed 1
+5
not commented 2026-09-25 08:40:48 +00:00
Contributor
Copy Link
Copy Source

What & why

Follow-up to #179. After login through https://big-mijn.labs.respellion.tech, the browser blocked the token request as mixed content. KC_HOSTNAME_BACKCHANNEL_DYNAMIC=true makes Keycloak build its token, userinfo and certs URLs from the incoming request. Behind the labs Caddy that request arrives as plain http, so the discovery document listed http://big-auth…/token.

KC_PROXY_HEADERS=xforwarded makes Keycloak trust the X-Forwarded-Proto: https that Caddy sends. In-cluster calls (the BFF → keycloak:8080) carry no such header, so they are unchanged, and so is the localhost/NodePort setup.

Refs #177

Definition of Done

  • Linked Gitea issue (above).
  • Failing test committed before the implementation. (One env var, verified live instead.)
  • Conventional Commits referencing the issue (refs #NN).
  • CI green
  • Docs updated if behaviour, contracts, or operations changed. (Comment in values.yaml.)

Notes for reviewers

  • I already applied this to the running cluster with kubectl set env and checked it. Both realms' discovery documents now have 0 http:// URLs, and a jan-burger token from the public Keycloak still gets a 204 from the BFF. Merging keeps the next deploy from reverting it.
  • Keycloak now trusts X-Forwarded-* from anything that can reach it. Its only entry points are in-cluster callers and the NodePort, which the reverse tunnel exposes only to Caddy. KC_PROXY_TRUSTED_ADDRESSES could narrow that if the NodePort is ever exposed more widely.

🤖 Generated with Claude Code

## What & why Follow-up to #179. After login through `https://big-mijn.labs.respellion.tech`, the browser blocked the token request as mixed content. `KC_HOSTNAME_BACKCHANNEL_DYNAMIC=true` makes Keycloak build its token, userinfo and certs URLs from the incoming request. Behind the labs Caddy that request arrives as plain `http`, so the discovery document listed `http://big-auth…/token`. `KC_PROXY_HEADERS=xforwarded` makes Keycloak trust the `X-Forwarded-Proto: https` that Caddy sends. In-cluster calls (the BFF → `keycloak:8080`) carry no such header, so they are unchanged, and so is the localhost/NodePort setup. Refs #177 ## Definition of Done - [x] Linked Gitea issue (above). - [ ] Failing test committed before the implementation. *(One env var, verified live instead.)* - [x] Conventional Commits referencing the issue (`refs #NN`). - [ ] CI green - [x] Docs updated if behaviour, contracts, or operations changed. *(Comment in values.yaml.)* ## Notes for reviewers - I already applied this to the running cluster with `kubectl set env` and checked it. Both realms' discovery documents now have 0 `http://` URLs, and a `jan-burger` token from the public Keycloak still gets a 204 from the BFF. Merging keeps the next deploy from reverting it. - Keycloak now trusts `X-Forwarded-*` from anything that can reach it. Its only entry points are in-cluster callers and the NodePort, which the reverse tunnel exposes only to Caddy. `KC_PROXY_TRUSTED_ADDRESSES` could narrow that if the NodePort is ever exposed more widely. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
not added 1 commit 2026-09-25 11:35:44 +00:00
fix(k8s): keep Keycloak's backchannel URLs https behind the labs Caddy (refs #177)
CI / lint (pull_request) Successful in 1m44s
Details
CI / k8s (pull_request) Successful in 9s
Details
CI / build (pull_request) Successful in 1m21s
Details
CI / unit (pull_request) Successful in 1m31s
Details
CI / frontend (pull_request) Successful in 2m31s
Details
CI / mutation (pull_request) Successful in 4m47s
Details
CI / verify-stack (pull_request) In progress
Details
61730657e6 
KC_HOSTNAME_BACKCHANNEL_DYNAMIC builds the token/userinfo/certs URLs from the
request, which reaches Keycloak as plain http through the proxy, so browsers
blocked them as mixed content after login. Trust X-Forwarded-Proto.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
not force-pushed fix/keycloak-proxy-headers from 3c3c1f7a17 to 61730657e6 2026-09-25 11:35:44 +00:00 Compare
Some checks are pending
CI / lint (pull_request) Successful in 1m44s
Required
Details
CI / k8s (pull_request) Successful in 9s
Details
CI / build (pull_request) Successful in 1m21s
Required
Details
CI / unit (pull_request) Successful in 1m31s
Required
Details
CI / frontend (pull_request) Successful in 2m31s
Required
Details
CI / mutation (pull_request) Successful in 4m47s
Required
Details
CI / verify-stack (pull_request) In progress
Required
Details
Some required checks are missing.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin fix/keycloak-proxy-headers:fix/keycloak-proxy-headers
git checkout fix/keycloak-proxy-headers
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
area:acl
area:bff
area:docs
area:domain
area:event-subscriber
area:infra
area:portal-behandel
area:portal-beheer
area:portal-openbaar
area:portal-self-service
area:projection
area:workflow
type:adr-proposal
type:bug
type:chore
type:slice
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
eho (Edwin van den Houdt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#180