To simplify service port management between Docker containers I would like to allow the contained HTTP services to listen on HTTP's default TCP port 80 of their respective container's IP address.
Listening to port numbers below 1025 is classically restricted to users with special privileges, such as root. The reason for this, as far as I understand, is to prohibit non-privileged users on multi-user systems to act as the authoritative HTTP service for the whole machine.
In newer Linux versions it is also possible to allow this to specific executables by applying the Linux kernel capability CAP_NET_BIND_SERVICE. For this to work in Docker containers I also seem to need to apply this capability to the Docker container itself, either through the --add-cap flag on the Docker client or the Docker-Compose cap_add section.
Theoretically, the reason for this port number restriction is obsolete in this case, because the Linux kernel's network namespacing allows the processes within the container only to bind on their very own IP addresses which are exclusive to them.
My question now would be, if there are any serious caveats about doing this. Is this or could this become in any way a security problem in way unconsidered by me? Or are there any other issues about doing this?
I see zero issues in doing this.
While it is possible to use "cap add" and cause security holes to be exposed, allowing port 80 to be used is not an issue. It's just a TCP/IP port where your software listens, and from a security perspective it's no different than any other random port number.
For the moment I'd recommend to just bind to other ports. One an always forward them to another port when the container is created. Messing around with security and leaving unnecessary privileges in the container seems too much trouble to just internally bind to a specific port.