With --net=host I can expose all of my hardware network interfaces to a container, but I want to expose just one. Exposing all would seem ridiculous when I plan that some might be generated by the very container I’m planning. It’s also an unnecessary security risk to be forced to expose bits of hardware to a container for no particular reason - let’s not forget that pretty much anybody can publish an image, and not every admin of every docker system is going to read every detail of every image before running it.
Why do I want this? What I have planned is a system of DSL/VPN dialers and wireless access points connected by docker bridge networks, and I want fine control over which container sees which HW. Specifically, I’m servicing a block of 8 IPs, so there’d be a DSL dialer container that knows my DSL creds and finds the modem on the physical eth0, and connects ppp0 to an invented docker bridge network where several WAPs and web servers hang on some of my 5 free IPs (after losing the dialer’s inside and outside IPs and the broadcast IP.)
The multilpe WAPs are sorting out different visibilities and DNS configs. The house WLAN knows the names of my various domestic media servers, the guest WLAN only reaches 8.8.8.8 and my work WLAN dials my employer’s VPN and defers to their DNS but not mine.
So the problem I had showing eth0 to the dialer container recurs when the WAPs want to see the physical high-gain WLAN transceiver. They are strictly limited in what HW and docker networks they should see, even if I don’t know exactly what code they’re running. (I’m not even sure that multiple containers can use the same WLAN device although I expect that multiple hostapd processes on the native OS can.)
I thought of using linux bridges to get around this: perhaps I can bridge eth0 to a docker network, but that would be messy.
All I really want is the same thing that --net=host does, but piecemeal. That seems to harmonise cleanly with the current design.
Does anyone else think this would be a useful feature?
Adrian.