Portainer registers the OIDC provider through its own API and ships no podman-configure-oidc.service, so identity:identity only logged a spurious restart failure each update. Relies on the configureService="none" support just added upstream.
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.
Podman is the container foundation, Portainer CE is the web interface onto it,
running as a container on the very engine it manages. This is what the separate
portainer module already did, so it is retired rather than duplicated.
Two sockets on purpose: the rootful one is the Docker-compatible API Portainer
drives (it does not support rootless), the rootless user socket is for people
who ssh in and run containers by hand — which was the original podman module's
point and is worth keeping.
An explicit proxyDomain lets the module publish at the environment's own domain
instead of <module>.<environment-domain>, making it that environment's gateway.
DESIGN.md keeps the Cockpit identity analysis: it is the reason for the change,
and anyone proposing 'just put Cockpit behind forward-auth' should read it.
Cockpit is not an OIDC client and cannot be configured into one, so
identity:identity is the wrong dependency. Records the three real options —
accessControl URL gating, an Authentik LDAP outpost with SSSD, and a custom
Cockpit auth command — with the recommendation to take the first, raise the
second upstream, and leave the third alone.
Also flags that accessControl's install-service requires proxyDomain in the
resolved config and, unlike identity's, does not derive it — to verify on a
live install before relying on it.
README, a module-catalog.json validated against TAPPaaS's
module-catalog-fields.json, and the podman module copied verbatim from
Community/src/larsrossen/containers/podman into a flat src/containers/ layout
(the catalog carries the explicit moduleJson path, so layout is free).
