There are many use cases where you will need to map a port for a docker container because the underlying application is very difficult to map to a privileged port. The canonical example is Apache Tomcat. When running it as a non-privileged user you will need to use authbind to have it listen on port 80. This is a bit of a nightmare to get setup correctly in Docker. Moreover, I've had applications totally refuse to play with authbind inside docker. In those cases, port forwarding was a savior.
Added to the severity of this is that we don't support an emulation of port forwarding via iptables, so we are left with sub-par solutions like socat. In a lot of cases, users will host behind load balancers so this becomes a non-issue, but there are still many use cases where you will want a privileged port.
Josh Wilsdon commented on 2015-04-20T11:46:09.000-0400 (edited 2018-05-07T13:50:43.945-0400):
Out of curiosity, do none of these applications offer the ability to run as root and bind to the correct port? Or is that just painful to configured for the docker image? If running as root you won't need to authbind.
Former user commented on 2015-04-20T14:18:34.000-0400:
Some dockerized applications run as root. Many run as unprivileged users in order to provide another layer of security. For sdc-docker, that security doesn't matter so much, but it does matter on lxc-docker and that's what most people are thinking of when they are building docker images.
When I dockerize an application, I always run the application from a non-root account because if you application gets p0wned, then the attacker has another stage of privilege escalation to go through.
Docker recommends the same approach (in the conclusion section): http://docs.docker.com/articles/security/
If memory serves me correctly, when they are running as root they bind correctly.
Former user commented on 2015-04-20T18:24:24.000-0400 (edited 2015-04-20T18:25:55.000-0400):
using ipnat (part of ipfilter) might be an option, but would need to be exposed in orchestration. for reference: ipnat.conf(4) and ipnat(4), specifically, handling of the redir (rdr) command
Former user commented on 2015-04-20T19:52:36.000-0400 (edited 2015-04-21T15:35:12.000-0400):
We have a few options on the orchestration side:
1) Either make fwadm (+ FWAPI) or vmadm have some ability to do port redirection (plus potentially NATing). This would likely work similar to how fwadm does things under the hood: create /zones/:uuid/config/ipnat.conf, and the brand scripts could run the appropriate ipnat commands (rdr, as Troy said above).
2) Set a docker:rdr_tcp_ports or the like in internal_metadata and have dockerinit know how to process that value. There's no library interface to ipnat (unless we want to call the ioctls directly), so this would have to exec ipnat in much the same way as the brand scripts above.
Since both options #1 and #2 are fairly similar, we probably want to go with #1, since it can be used for non-docker zones as well. A VM property similar to the vmadm "routes" object mapping source to destination ports might be reasonable here.
The real blocker, however, is that using rdr in ipnat goes through the IP forwarding path in illumos - this means that unless antispoof is disabled, redirected packets will be dropped by the antispoof code. Disabling antispoof is definitely something we can't allow for customer-controlled zones.
Former user commented on 2015-06-12T21:58:00.000-0400:
Pinging @Former user
This issue is becoming increasingly important now that I will be demoing ecommerce platforms in Java. Not having this is a bit crippling...
Former user commented on 2015-09-02T18:54:05.000-0400:
This is my periodic reminder that this is important. At the very least, we need to think about how we will design our systems so that this can be supported in the future. In fact, an infamously angry customer burned us on just this one: "docker -p is the default port management command in Docker. This is docker network 101.
I am not sure why port maps are not allowed but we cannot work around it."
Brian Bennett commented on 2015-09-12T15:07:12.000-0400 (edited 2019-05-02T14:06:25.224-0400):
FWIW, I just had a short conversation on Twitter about this:
https://twitter.com/nicholaswyoung/status/642775074865459200
Can we make this issue public?
Former user commented on 2016-07-31T13:58:41.000-0400:
I just discovered that Alpine Linux doesn't have support for authbind. This means that there is no good way to get non-privileged processes running on privileged ports (e.g. 80).
Former user commented on 2018-05-22T12:07:32.110-0400:
With the reduced investment in docker, we'll not spend time on this improvement. We'll file a new ticket or reopen this if the need comes up again.