diff --git a/src/containers/podman/INSTALL.md b/src/containers/podman/INSTALL.md index 80eb687..163f2c6 100644 --- a/src/containers/podman/INSTALL.md +++ b/src/containers/podman/INSTALL.md @@ -85,6 +85,19 @@ are worth knowing when debugging: `copy-update-json.sh` documenting that `install-module.sh` computes it, so consumers must derive it — from the module's **own** environment, never the default one. +## Publishing the gateway publicly + +The module ships internal-only. To expose it (lab1 does this): + +```bash +jq '(.config."network:proxy".proxyAllowedZones) = ["internet"]' \ + ~/config/podman-.json > /tmp/p.json && mv /tmp/p.json ~/config/podman-.json +~/TAPPaaS/src/foundation/network/services/proxy/update-service.sh podman- +``` + +Read the warning in [README.md](./README.md#publishing-to-the-internet) first: the local admin +login stays reachable over `/api/auth` once the network restriction is gone. + ## Verify ```bash diff --git a/src/containers/podman/README.md b/src/containers/podman/README.md index e0a0bea..fbe44f0 100644 --- a/src/containers/podman/README.md +++ b/src/containers/podman/README.md @@ -70,9 +70,26 @@ the intent; if you need per-person isolation, CE will not give it to you. ## Placement No `zone0` is set, so the VM lands in the environment's zone (ADR-007 P5). -`proxyAllowedZones` is deliberately unset, which gives the internal default — every Active -service zone plus `home`, `work`, `mgmt` and the netbird overlay, but **not** the internet — so -members reach the console from a client zone while Authentik decides who gets in. +`proxyAllowedZones` unset gives the internal default — every Active service zone plus `home`, +`work`, `mgmt` and the netbird overlay, but **not** the internet. Note the operator's admin-VPN +overlay (`admin`, `10.255.1.0/24`) is *not* in that default, so a remote admin on the WireGuard +tunnel gets `403` too. Set `proxyAllowedZones: ["internet"]` to publish it — but read the +warning below first. + +## Publishing to the internet + +`proxyAllowedZones: ["internet"]` removes the network restriction, leaving Authentik as the +gate. That is *almost* true, and the gap matters: + +**Enabling OAuth does not disable Portainer's internal login.** `POST /api/auth` stays live and +still accepts the break-glass admin, whatever the UI shows — verified against the public +endpoint, which answers `422 Invalid credentials` rather than refusing the path. So publishing +the console also publishes a username/password path for the local `admin`. + +The password is 32 random base64 characters, so guessing it is not the threat; an +authentication bypass in Portainer itself would be. If you want "gated by identity" to be +literally true, promote an OIDC user to administrator and then delete the local admin — +accepting that an Authentik outage then locks everyone out until the volume is restored. ## Sizing