Portainer Built-in Authentication vs. Reverse Proxy Allowlist for Restricting UI Exposure

A Portainer CE 2.x deployment serves its web UI on port 9000, and when that port is published on all interfaces the instance can become reachable from networks that should never see it. The decision is where access control should live: inside Portainer or in a layer in front of it.

Portainer provides built-in username/password authentication and, in recent releases, an IP allow-listing setting that limits which source addresses can open the UI. The documented alternative is a TLS-terminating reverse proxy that applies allow/deny rules before requests reach Portainer at all. The trade-off is not obvious: internal controls keep the stack simple and continue to work if the proxy is removed, while proxy-level filtering shields the login page itself and supplies TLS independently of Portainer's own settings. It is not clear which arrangement is intended as the production default.

1. Is Portainer's built-in IP allowlist sufficient on its own, or is a reverse proxy with allow/deny rules the expected production pattern?
2. Does the built-in allowlist block disallowed addresses before the login page is served?
3. If both layers are configured, which one should own the restriction so the rules cannot conflict or silently widen access?