Docker安全性最佳实践

您可以在Internet上找到的大多数Dockerfile都以root身份构建和运行软件！这必须吓唬大家，对吧？ ...但似乎并非如此...Docker安全性最佳实践

因此，pb是运行一个服务器作为根，即使在一个容器中，是危险的，因为容器内的根与根相当在容器外面。

其中一个解决方案是通过使用“USER”指令（如this example for a tor relay）正确构建Dockerfile。

另一种解决方案是使用“linux用户名空间”将容器内的UID/GID“映射”到容器外部的UID/GID。例如，在一个容器内的根（uid = 0）可以映射到主机内的个人用户帐户，因此在共享卷中创建的文件具有良好的权限。

所以我的问题是：当涉及到Docker的安全性时，最佳实践是什么？以非根的方式运行代码（即Dockerfile中的USER指令）？或通过使用“用户名称空间”？或者最终（或另外）使用selinux和/或AppArmor？

谢谢:)

来源

2014-12-02 kondor

我也想补充一点，它通常是不希望运行的应用程序（例如像Web服务器）作为根 – kondor 2014-12-09 14:24:55

这个文件看起来有趣： [泊坞窗安全部署指南] （https://github.com/GDSSecurity/Docker-Secure-Deployment-Guidelines） – kondor 2015-01-23 12:32:58

报价Solomon Hykes

大家好，我是码头工人的维护者。正如其他人已经表明，这不适用于1.0。但它可能有。

请记住，在这个时候，我们并没有声称Docker立即可用于包含具有root权限的不受信任的程序。所以如果你想“我们升级到1.0或者我们敬酒的好东西”，你现在需要改变你的底层配置。添加apparmor或selinux遏制，将信任组映射到单独的机器，或理想情况下不授予对应用程序的根访问权限。

因此，就最佳实践而言，如果您对安全性有严肃认识，那么命名空间和apparmor或selinux是肯定的。话虽如此，但很多人并不在乎去追加额外的麻烦（无论好坏），所以你看到很多人不会去麻烦。为容器内的文件（特别是装载为卷的文件）的用户设置权限有时会变得棘手，这就是很多人跳过额外的开销。

来源

2014-12-24 16:34:05