Docker 安全性最佳实践

Question

大多数

Dockerfile都可以在互联网上以root身份构建和运行软件！这一定会吓到所有人，对吧？...但事实似乎并非如此...

所以pb是，即使在容器中以root身份运行服务器也是危险的，因为容器内的root与容器外的root完全相同。

解决方案之一是使用"USER"指令正确构建 Dockerfile，就像这个 tor 中继的例子一样。

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

所以我的问题是：当涉及到Docker的安全性时，最佳实践是什么？以非root身份运行代码(即Dockerfile中的USER指令(？还是通过使用"用户命名空间"？或者最终(或另外(通过使用selinux和/或AppArmor？

谢谢:)

Answer 1

引用所罗门·海克斯

的话

大家好，我是 Docker 的维护者。正如其他人已经指出的那样，这在 1.0 上不起作用。但它可以。

请记住，目前，我们不声称 Docker 开箱即用适合包含具有 root 权限的不受信任的程序。因此，如果您正在考虑"pfew，还好我们升级到 1.0 或我们被烤面包"，您需要立即更改底层配置。添加 apparmor 或 selinux 包含，将信任组映射到单独的计算机，或者理想情况下不要授予对应用程序的根访问权限。

因此，就

最佳实践而言，如果您对安全性很认真，那么命名空间和apparmor或selinux是肯定的。话虽如此，很多人并不关心去找额外的麻烦(无论好坏(，所以你看到很多人不会去找麻烦。为用户设置容器内文件的权限(特别是作为卷挂载的文件(有时会变得棘手，这是很多人跳过额外开销的方式。

Answer 2

除了 SELinux、Apparmour、GRSEC 之外，cgroups 还提供了隔离和限制容器资源使用的额外好处，如果配置谨慎，这有助于防止一个受损容器影响另一个容器。指

Answer 3

最佳做法是根据 CIS 安全基准一起遵循问题末尾提到的所有三个选项：

1. 容器内的非 root 用户(第 4.1 节(
2. 启用用户命名空间(第 2.8 节(
3. 在执行模式下启用 MAC，即 SELinux 或 AppArmor(第 5.2 节(

参考资料： https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.12.0_Benchmark_v1.0.0.pdf