TAPPaaS/makerfloss
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

podman: document internet exposure and what identity does not gate

Browse source 
lab1 is now published with proxyAllowedZones: [internet]. Enabling OAuth does
not disable Portainer's internal login — POST /api/auth stays live and still
accepts the break-glass admin, confirmed against the public endpoint (422
Invalid credentials, not a refused path). So publishing the console publishes a
password path too; the remedy, if that is unacceptable, is to promote an OIDC
user to administrator and delete the local admin, at the cost of break-glass.

Also records that the operator's admin-VPN overlay (admin, 10.255.1.0/24) is
not in the internal default allow-set, which is why a remote admin on the
WireGuard tunnel also gets 403.
This commit is contained in:
Lars Rossen 2026-08-25 09:56:01 +02:00
parent 04b4437c95
commit 828b2c3f1b
2 changed files with 33 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/containers/podman/INSTALL.md
View file

@ -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-<env>.json > /tmp/p.json && mv /tmp/p.json ~/config/podman-<env>.json
~/TAPPaaS/src/foundation/network/services/proxy/update-service.sh podman-<env>
```
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

23
src/containers/podman/README.md
View file

@ -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