Does uwsgi http-socket default binding risk public exposure in host-networked containers?
0 reputation · 12 May 2023, 00:00 UTC
In uWSGI 2.0.x, the --http-socket option defaults to binding on 0.0.0.0 when a port is specified without an explicit IP address. This differs from the uwsgi protocol socket, which typically defaults to 127.0.0.1.
When deploying applications within containerized environments, this behavior creates a potential security gap. While a standard Docker bridge network provides isolation, utilizing --network=host or Kubernetes hostNetwork: true bypasses this layer, potentially exposing the HTTP port directly to the external network without an intervening reverse proxy.
Operational requirements, such as health checks from orchestration platforms, often necessitate broad binding, yet there is no native uWSGI mechanism to alert administrators when an HTTP socket is bound to all interfaces in a production context.
Technical Uncertainties
- Which configuration strategy best balances the need for external health checks with the requirement to prevent accidental public exposure?
- Does uWSGI provide a mechanism to restrict
--http-socketto specific internal interfaces without manually hardcoding IP addresses for every environment?