Portainer Server bind address and missing public access constraint

Bind address configuration

Bind the management UI ports (9000 HTTP, 9443 HTTPS) to a trusted management-network interface only, and bind the Edge Agent tunnel port (9001) to the interface that remote agents can reach. In Docker this is done per-port mapping:

docker run -d \
  -p 192.168.10.5:9000:9000 \
  -p 192.168.10.5:9443:9443 \
  -p 0.0.0.0:9001:9001 \
  portainer/portainer-ce:latest

In Docker Compose:

services:
  portainer:
    image: portainer/portainer-ce:latest
    ports:
      - "192.168.10.5:9000:9000"
      - "192.168.10.5:9443:9443"
      - "0.0.0.0:9001:9001"

Replace 192.168.10.5 with the IP of your trusted management NIC. The tunnel port (9001) can remain on 0.0.0.0 or a specific public IP if agents connect over the internet; restrict it with host firewall rules to known agent source ranges.

No built-in RBAC boundary for bind addresses

Portainer's role-based access control governs logical resources (environments, stacks, users) but does not constrain the network interfaces the server process binds to. An administrator with UI access can change the published ports in the container runtime (Docker, Kubernetes, etc.) and redeploy. Bind-address control is a host-level concern—enforce it with firewall rules, security groups, or a reverse proxy (Traefik, Nginx) that terminates TLS and applies IP allow-lists in front of ports 9000/9443.

First-run authentication timing

The Portainer web server starts listening on its configured ports immediately at container startup. The first HTTP request to the UI serves the initial-setup page where the admin password is created. There is no authentication gate at the TCP or HTTP layer before that page loads. If the UI ports are reachable from an untrusted network during this window, anyone who reaches the setup page first can set the admin password and take ownership.

Verification steps

1. After startup, run docker port <container> to confirm which host IPs and ports are mapped.
2. From a trusted host: curl -k https://<mgmt-ip>:9443 should return the Portainer UI (or setup page).
3. From an untrusted host: the same request should time out or be refused.
4. Deploy an Edge Agent pointing to <server-fqdn>:9001 and verify it appears in Portainer → Edge Agents.
5. Check ss -ltnp | grep -E '9000|9001|9443' on the host to verify listen addresses match intent.

One diagnostic detail needed

What is the network topology between your Portainer host and the Edge Agents (same VPC, internet, site-to-site VPN, overlay network)? The answer determines whether the tunnel port should bind to 0.0.0.0, a specific public IP, or a VPN interface, and whether additional firewall rules are required on the tunnel port itself.