Secure alternatives to DiD or the UNIX socket?
<p>I'm trying to learn more about Docker, what it's for, and how it functions. To that end, I've set up two containers using <code>docker-compose</code>:  </p>

<ul>
<li>One container, based on Docker's <code>python:3</code> image, runs some service  </li>
<li>The other container, also based on Dockers's <code>python:3</code> image, contains a Django app.<br>
The reason for using Docker is that it seemed like a great way to ensure functionality across different systems. </li>
</ul>

<p>My purpose is to have an HTTP-served interface (the Django app), to manage the other container. I seek to be able to issue commands to the service container, through the Django app. Usually, this would be done through <code>docker exec $container_ID &lt;command&gt;</code>. However, the Django app is of course not able to call the <code>docker</code> command just like that, given it's in a container itself. All of this is served on my LAN, not exposed to the web.</p>

<p>Right now, from what I understand, I have these options to give Django <code>docker exec</code> privilege/functionality on the other container:  </p>

<ul>
<li><strong>Use Docker-in-Docker:</strong> However, from what I gather, even the author of DiD recommends <a href="https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/" rel="nofollow">against using DiD</a>, unless you have a very specific, suitable purpose. Instead, he recommends you use:  </li>
<li><strong>The Docker UNIX socket,</strong> using something like <a href="https://docker-py.readthedocs.io/en/stable/" rel="nofollow">docker-py</a> to do the magic. However, a cursory search shows that this is also iffy: any container having access to the socket effectively has root access to the host file system <a href="https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html" rel="nofollow">[1]</a> <a href="https://www.ctl.io/developers/blog/post/tutorial-understanding-the-security-risks-of-running-docker-containers" rel="nofollow">[2]</a>, if I understood correctly (which I'm not entirely sure of). I'm not expecting malware on my LAN anytime soon (knock on virtual wood), but the matter still bugs me: if an attacker finds a way to gain control of the Django container, they effectively have a free privilege escalation to the host system. There's a <a href="https://integratedcode.us/2016/04/20/sharing-the-docker-unix-socket-with-unprivileged-containers-redux/" rel="nofollow">Docker post</a> showing how you could deal with this, but it does not seem to be a full-fledged Docker functionality (yet?). The explanation is relatively technical and I am not yet quite at that level of expertise to fully grasp it.  </li>
<li><strong>Hackity hack</strong> using shared volumes. Basically the Django container writes the commands to a shared file, and the service container periodically reads that file and executes the commands it finds inside. I'm not sure whether this is realistic, or whether I will end up in networking hell though, I just came up with it.</li>
</ul>

<p>Is there another Docker functionality that I missed that allows me to fulfil my inter-container-management needs?</p>

<p>You can do what you want (of course if I understood well) like this:</p>

<p><code>
docker run -d -v /var/run/docker.socket:/var/run/docker.socket -v $(which docker):/usr/bin/docker manager-app:latest
</code></p>

<p>Then you can use docker binary to access the other containers on the host and manage your service containers.</p>

<hr>

<p>Since you asked for other ways, I can propose two:</p>

<ul>
<li>Use Docker TCP socker instead and set DOCEKR_HOST env in your container to docker host IP then you don't need socker anymore (it's less secure, make sure you have proper firewall to protect you docker from outside world or use a network which is not routerd/nat) </li>
</ul>

<p>Or</p>

<ul>
<li>Embed a small API in your service containers to run the command on your behalf, this way you don't need docker functionality all all.</li>
</ul>

python docker docker-compose