一段时间以来，我们一直在计划引入securityContext: runAsNonRoot: true作为我们pod配置的要求。
今天进行测试，我了解到自v1.8.4（我认为）以来，您还必须为运行容器的用户指定特定的UID，例如runAsUser: 333。
这意味着我们不仅必须告诉开发人员确保其容器不是以root用户身份运行，而且还指定了他们应以其身份运行的特定UID，这给我们引入了很多麻烦。
我正确理解了吗？其他人在这方面做什么？要利用runAsNonRoot，现在是否需要Docker容器以特定的已知UID运行？
答案 0 :(得分：3)
Kubernetes Pod SecurityContext提供两个选项runAsNonRoot和runAsUser来强制非root用户。您可以将两个选项彼此分开使用，因为它们会测试不同的配置。
设置runAsNonRoot: true时，您要求容器将与用户UID都不为0一起运行。无论您的用户具有哪个UID。
设置runAsUser: 333时，要求该容器将与UID 333的用户一起运行。
答案 1 :(得分：0)
这方面的其他人在做什么？
在不希望使用root用户的情况下，我们使用runAsUser。当然，这种情况并不像您想象的那么频繁，因为在kubernetes集群体系结构中将“进程”部署为分离的pod容器的理念不同于在单个主机上的传统复合整体式部署，在传统上，违规的安全隐患完全不同... < / p>
我们的大多数本地开发都是在带有k8s清单的minicube或docker edge上完成的，因此设置尽可能接近我们的部署集群（除了明显的限制）。话虽如此，我们没有用户ID分配的问题，因为持久性卷的初始化不是在外部完成的，因此所有文件用户/组所有权都是在具有适当文件权限的Pod中完成的。在极少数情况下使用docker进行开发时，会指示开发人员在已安装的卷之间手动设置适当的权限，但这种情况很少发生。