Block traffic to external ip without privileged mode

[jtblin]

Output of docker version:

Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.6.2
 Git commit:   b9f10c9
 Built:        Thu Jun  2 03:53:12 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:20:08 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 18
 Running: 0
 Paused: 0
 Stopped: 18
Images: 83
Server Version: 1.11.2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 110
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: null host bridge
Kernel Version: 4.4.12-boot2docker
Operating System: Boot2Docker 1.11.2 (TCL 7.1); HEAD : a6645c3 - Wed Jun  1 22:59:51 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.9 MiB
Name: default
ID: S3YO:RKQR:5M6N:P3VM:HJDV:3ROC:GJZD:UGYQ:VD45:MEDG:U4FF:HAF3
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug mode (client): false
Debug mode (server): true
 File Descriptors: 12
 Goroutines: 30
 System Time: 2016-06-22T12:59:53.896071089Z
 EventsListeners: 0
Username: jtblin
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

Additional environment details (AWS, VirtualBox, physical, etc.):
Example docker image

FROM alpine:3.4

RUN apk --no-cache add \
    git \
    iptables \
    ca-certificates

ADD entrypoint.sh /bin/entrypoint.sh

ENTRYPOINT ["entrypoint.sh"]

Steps to reproduce the issue:
Run the following command inside a container that has iptables installed:

iptables -A OUTPUT -d 169.254.169.254 -j DROP

Describe the results you received:
I get the following error:

iptables v1.6.0: can't initialize iptables table `filter': Permission denied (you must be root)

Describe the results you expected:
This is related to #4424. I need to run an iptables command inside the docker container but I cannot use the -privileged option as it is a shared platform. I basically need to prevent traffic from inside the container which executes non trusted code to access the ec2 metadata API.

Additional information you deem important (e.g. issue happens only occasionally):

[jtblin]

To clarify, I don't want to block anything on the host where I understand the need for --privileged, I just want to block the traffic within the container. I've also tried other options but they fail as well with related errors e.g.

route add -host IP-ADDRESS reject

route: ioctl 0x890b failed: Operation not permitted

ip route add blackhole 169.254.169.254

ip: RTNETLINK answers: Operation not permitted

[gordonsyme]

It's not possible to manipulate iptables from within an unprivileged docker container. Containers share the same kernel as the host, you need root (or the relevant capabilities) to interact with the iptables settings.

FWIW giving those capabilities to a container running untrusted code is a really bad idea.

You're better off setting iptables rules from where they are meant to be set, the host.

/sbin/iptables --insert FORWARD 1 --in-interface docker+ --destination 169.254.0.0/16 --jump DROP

will drop any traffic from any bridge interface named dockerN (presuming you're using bridged networking) to the zeroconf network, which is where the EC2 metadata API lives.

If you're creating a new bridge per container then you'll need to tweak the interface pattern.

There is one major problem with this approach, which I'm currently checking to see if it's already been filed. I'll update this comment with a link once I either find it or create it.

[gordonsyme]

Related: #23897

[jtblin]

Thanks @gordonsyme. The problem is that I don't have access to the host. It's a bit ironical that we cannot isolate from within the container directly.

[gordonsyme]

@jtblin in that case the best course of action is to talk to someone who does have access to the host, the responsibility to filter what hosted containers can and can't do lies with them.

[cpuguy83]

Well, it's a bit weird to have the container contain itself.
You can do docker run --net=none, or potentially a network plugin that disables external traffic (could probably just wrap the bridge driver with the extra iptables calls).

You can also do this at the network level:

$ docker network create --internal

[thaJeztah]

I don't think there's a bug here, and @cpuguy83 mentioned some options that should resolve this case, so I'm closing this issue, but feel free to continue the discussion