5

您可以在 Internet 上找到的大多数 Dockerfile 都以 root 身份构建和运行软件！这一定吓到大家了吧？……但好像不是这样的……

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

解决方案之一是通过使用“USER”指令正确构建 Dockerfile，例如 Tor 中继。

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

所以我的问题是：关于 D​​ocker 的安全性，最佳实践是什么？以非 root 身份运行代码（即 Dockerfile 中的 USER 指令）？或者通过使用“用户命名空间”？或者最终（或另外）使用 selinux 和/或 AppArmor ？

谢谢 ：）

4

3 回答 3

3

引用所罗门海克斯的话

大家好，我是Docker的维护者。正如其他人已经指出的那样，这不适用于 1.0。但它可能有。

请记住，此时，我们并不声称 Docker 开箱即用适用于包含具有 root 权限的不受信任的程序。因此，如果您在想“pfew，我们升级到 1.0 的好事，或者我们干杯了”，您现在需要更改您的底层配置。添加 apparmor 或 selinux 遏制，将信任组映射到单独的机器，或者最好不要授予对应用程序的 root 访问权限。

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

于 2014-12-24T16:34:05.557 回答
1

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

于 2014-12-25T05:39:41.600 回答
1

根据 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

于 2016-11-01T03:28:02.417 回答