docs(k8s): how to reach the deployed portals from a laptop (refs #175)
The five forwards are not optional and not independent: the portals' OIDC authority is pinned to localhost:30180, so forwarding the portal without Keycloak gets ERR_CONNECTION_REFUSED on the discovery document and an opaque "[object Object]" in the console. One ssh replaces `make k8s-portals` for the lab server, and needs no kubeconfig. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -427,6 +427,26 @@ Settings, all on the repository in Gitea:
|
||||
The last step smokes `GET /openbaar/register` through the openbaar portal, which exercises
|
||||
portal → Caddy → BFF → projection. An empty register passes; a 502 does not.
|
||||
|
||||
### Reaching the portals from a laptop
|
||||
|
||||
The deployed portals are pinned to `http://localhost:30180` for Keycloak (§5), so a browser
|
||||
needs **all five** browser-facing ports on its own localhost — the portal alone is not
|
||||
enough, and a missing Keycloak shows up as `ERR_CONNECTION_REFUSED` on
|
||||
`/realms/*/.well-known/openid-configuration` followed by an opaque `ERROR Error: [object Object]`.
|
||||
`make k8s-portals` does this when kubectl can reach the cluster; through the lab server one
|
||||
SSH does it without a kubeconfig at all:
|
||||
|
||||
```bash
|
||||
ssh -N -p 6667 \
|
||||
-L 30140:<TALOS_VM_IP>:30140 -L 30141:<TALOS_VM_IP>:30141 \
|
||||
-L 30142:<TALOS_VM_IP>:30142 -L 30143:<TALOS_VM_IP>:30143 \
|
||||
-L 30180:<TALOS_VM_IP>:30180 \
|
||||
user@labs.respellion.tech
|
||||
```
|
||||
|
||||
Then the §5 table's URLs work as written. The admin UIs (OpenZaak, Flowable, …) need no
|
||||
forward — they are server-rendered, so the VM's address is fine.
|
||||
|
||||
Not covered: the portals still need `make k8s-portals` (or an SSH forward) to be usable in a
|
||||
browser, because PKCE needs a secure context (§5). Giving the server a hostname + TLS is the
|
||||
upgrade path.
|
||||
|
||||
Reference in New Issue
Block a user