在 Kubernetes 中使用 runAsNonRoot

Question

我们已经计划了很长时间，将

securityContext: runAsNonRoot: true

作为我们 pod 配置的要求已经有一段时间了。

今天测试这一点，我了解到，自从

v1.8.4

（我认为）以来，您还必须为运行容器的用户指定特定的 UID，例如

runAsUser: 333

。

这意味着我们不仅必须告诉开发人员确保他们的容器不以 root 身份运行，还要指定他们应该运行的特定 UID，这使得我们引入这个问题变得更加困难。

我的理解正确吗？其他人在这个领域做什么？为了利用

runAsNonRoot

，现在是否需要 Docker 容器使用特定且已知的 UID 运行？

Answer 1

Kubernetes Pod SecurityContext 提供了两个选项

runAsNonRoot

和

runAsUser

来强制执行非 root 用户。您可以单独使用这两个选项，因为它们测试不同的配置。

当您设置

runAsNonRoot: true

时，您要求容器将与具有除 0 之外的任何 UID 的用户一起运行。无论您的用户拥有哪个 UID。
当您设置

runAsUser: 333

时，您要求容器将与 UID 333 的用户一起运行。

Answer 2

其他人在这个领域做什么？

我们在不希望使用 root 的情况下使用

runAsUser

。当然，这些情况并不像您想象的那么频繁，因为在 kubernetes 集群架构内将“进程”部署为单独的 pod 容器的理念不同于单主机上传统的复合整体部署，其中违规的安全影响非常不同......

我们的大部分本地开发都是在带有 k8s 清单的 minicube 或 docker Edge 上完成的，因此设置尽可能接近我们的部署集群（除了明显的限制）。话虽如此，我们在用户 ID 分配方面没有问题，因为持久卷的初始化不是在外部完成的，因此所有文件用户/组所有权都是在具有适当文件权限的 pod 内完成的。在极少数情况下，使用 docker 进行开发，开发人员被指示跨已安装的卷手动设置适当的权限，但这种情况很少发生。

Answer 3

将其添加到 Dockerfile 解决了我的问题。这里9000是任意数字

USER 9000:9000