Service-level binding vs. networking.firewall for restricting public access

When deploying network services on NixOS, preventing accidental public exposure typically involves choosing between two documented mechanisms: restricting the service's listening address or utilizing the system firewall.

Implementation Trade-offs

Using networking.firewall.allowedTCPPorts allows for centralized management of network access, keeping the service configuration simple. However, the service still binds to 0.0.0.0, meaning any firewall misconfiguration or temporary disablement during updates could expose the socket.

Conversely, configuring service-specific options (such as services.postgresql.listenAddress) to bind exclusively to 127.0.0.1 reduces the attack surface at the socket level. This approach requires per-service configuration and may be less visible during a high-level system audit compared to a single firewall list.

Given these constraints, what are the primary architectural advantages of service-level binding over firewall-only restriction for internal-only tools? In what scenarios does the centralized nature of the NixOS firewall outweigh the security of localhost binding?