您将在Internet上找到大多数Dockerfile，并以root身份运行软件！ 这必须吓唬每个人，对吧？ ......但似乎并非如此......
所以pb是以root身份运行服务器，即使在容器中也是如此，因为容器内的root与容器外的root完全相同。
其中一个解决方案是使用＆＃34; USER＆＃34;正确构建Dockerfile。像this example for a tor relay这样的指令。
另一个解决方案是使用＆＃34; linux用户命名空间＆＃34;到＆＃34;地图＆＃34;容器内的UID / GID到容器外的UID / GID。例如，容器中的例如root（uid = 0）可以映射到主机内的个人用户帐户，因此在共享卷中创建的文件具有良好的权限。
所以我的问题是：Docker的安全性最佳做法是什么？以非root方式运行代码（即Dockerfile中的USER指令）？或者使用＆＃34;用户命名空间＆＃34; ？或者最终（或者另外）使用selinux和/或AppArmor？
谢谢：）
答案 0 :(得分：3)
大家好，我是Docker的维护者。正如其他人已经表明这在1.0上不起作用。但它可能有。
请记住，目前我们并未声称Docker开箱即用适合包含具有root权限的不受信任的程序。因此，如果您正在考虑“pfew，我们升级到1.0或者我们敬酒的好事”，您需要立即更改基础配置。添加apparmor或selinux包含，将信任组映射到单独的计算机，或者理想情况下不授予对应用程序的root访问权限。
因此，如果您认真对待安全性，那么对于命名空间和apparmor或selinux，最佳实践是肯定的。那就是说很多人都不在意这个额外的麻烦（无论好坏）所以你看到很多人都没有去找麻烦。为容器内的文件（特别是作为卷安装的文件）上的用户设置权限有时会变得棘手，这是许多人省去额外开销的方式。
答案 1 :(得分：1)
除了SELinux之外，Apparmour，GRSEC， cgroups 提供了隔离和限制容器资源使用的额外好处，如果配置得非常小心，这有助于防止一个受感染的容器影响另一个容器。 Refer
答案 2 :(得分：1)
根据CIS安全基准，最佳做法是一起遵循问题末尾提到的所有三个选项：
参考文献：https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.12.0_Benchmark_v1.0.0.pdf