我正在尝试使服务器上的 docker 更加安全。主要问题是大多数人说“如果一个人可以访问 docker，那么他们也可以是 root”，因为管理员很少这样做，这不是您想要的。
详细地说，他们可以使用-v并挂载/etc到/mnt容器中并更改影子文件并获得对主机的访问权限。他们也可以使用-d, 或特权选项来做更多事情。
所以基本上，我想“尝试”和限制一些事情。
- 卷绑定挂载
- 特权
--add-cap-d（某些项目？）
到目前为止我的想法：
- docker bash 脚本的别名，在其上使用 sudo 并正则表达式所有他们不应该做的事情。
- 打开远程 api，保护它，也许用 nginx 和 nginx 中的正则表达式对其进行反向代理，这是他们不应该做的事情。
- 使用其他工具？Mesos/马拉松/蜂群/造船厂/随便
可选项目是使容器提交到 git 代码，并让“检查器”验证内容Dockerfile并为它们创建图像。然后签署该映像并自动部署它。（但这不会再给他们太多的自由了）
此外，删除绑定卷也不是最好的。如果我们有一个 docker 插件，上面写着“你只能/data以用户 X 的身份挂载”，那会简单得多，其中那个USER是Dockerfile用户 X。
像docker-novolume-plugin这样的东西已经是卷的一个很好的开始，虽然不限制绑定卷。
最后的问题是，我怎样才能让用户以他们自己的用户/docker 身份构建/拉取/运行 docker 映像，而不能 root 系统。不一定是完美的，只要它有效。
保护
docker引擎需要关注许多不同的方面，而纵深防御总是与安全层有关。您列出的要求之一是限制用户可以命令
docker引擎执行的操作，这可能是最重要的要求之一，因为到目前为止，docker引擎还没有实现授权控制。您的选择包括：
像Twistlock这样的闭源解决方案，一个实现 RBAC 和策略控制以访问
dockerAPI的项目OpenShift Origin，一个开源项目，以安全约束和细粒度授权策略的形式实现基于角色的访问控制。它相当容易部署，并且对开箱即用的解决方案有很大帮助。
我还建议研究引擎可以部署到的不同操作系统
docker，并建议不要使用通用操作系统，而是使用专用操作系统，例如Atomic。Atomic 和 OpenShift 一起，将确保您还可以：dockerdocker套接字的访问，它将控制是否允许在容器之间共享文件描述符，它可以为每个容器/容器组分配不同的 MCS 级别，以将它们与主机和其他容器隔离。