Is it possible, with Docker, to bind a host network link exclusively to a Docker container?

In other words, to move eth1 (or whatever) into a container so that it is only avalilable to that container - neither the host nor any other containers/virtual machines, etc, running on the host should have access to it.

In Linux Containers (LXC) this is trivial, there is a phys network type that does exactly this:

phys: an already existing interface specified by the lxc.net.[i].link is assigned to the container.

I am not asking about routing or using macvlan or other hacks.

Ideally this will be possible using standard Docker commands, but from what I've read, I fear Docker's network implementation does not support this. A possible work-arounds using ip commands would be better than nothing.

1 Answer 1


This is not possible with standard network commands. Features that would make this easy were explicitly rejected by Docker a few years back (https://github.com/moby/moby/pull/8216).

You can of course manually move an interface into the network namespace of a Docker container, but this is fraught with problems: for example, any time you restart or re-create the container, you'll have to re-configure your networking.

To add an interface to your container's network namespace:

  1. Get the PID of your container:

    container_pid=$(docker inspect <container_name_or_id> -f '{{ .State.Pid }}')
  2. Assign the interface to the container's namespace:

    ip link set netns ${container_pid} dev ${device}

And you're done...mostly.

If you want to configure the interface after adding it to the namespace, you'll have to either:

  • Run your container with extra privileges. Probaly just --cap-add=NET_ADMIN, although you can also just use --privileged while you're testing things.

  • Use nsenter to perform the configuration from outside of the container:

    nsenter -t ${container_pid} -n ip addr ...

While this all works, because of the limitations I've noted, I would just stick with the macvtap driver if I need a physical interface inside the container for some reason. Or use lxc or systemd-nspawn or some other containerization tool that makes this particular task easier.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .