我想知道定义用户角色以分配给 Pod 和容器中的安全上下文的最佳方法是什么？
不建议以root用户身份授予用户，据我所知，如果用户的角色过于强大，那么当它将文件写入节点卷时以及下次部署新容器时，我们可能没有足够的权限删除强大用户写入容器中的文件的权限。
特别是，在 google Kubernetes 中，我想避免以下情况，例如在 docker 环境中部署应用程序时： 当 A 通过运行 docker 部署应用程序时： docker run ... 如果容器内的进程由比 A 更强大的用户 B 运行，那么 A 可能无法删除 B 写入的文件。 不确定这种情况是否会发生在 google K8S 中
一段时间后，我认为提到的场景在 K8S 中不会发生。 K8S 在重新部署、更新 pod 时会通过其内部机制来管理容器资源
【问题讨论】：
您可以将Linux Capabilities 与 Pod 和 Container 中的安全上下文混合，以便对传统上与超级用户（root 或 uid=0）关联的权限进行更细粒度的细分。其中一些功能可用于提升权限或用于容器突破，并且可能受 PodSecurityPolicy 限制。有关 Linux 功能的更多详细信息，请参阅capabilities。
也就是说，PodSecurityPolicy 将允许您控制 pod 规范的安全敏感方面，例如：分配拥有 pod 卷的 FSGroup、容器的用户和组 ID 以及另外的 Linux 功能以提供更好的权限。
对于Users and Groups，由于 RunAsUser (MustRunAs) 和 RunAsGroup (MustRunAs) 至少需要指定一个范围，那么您应该有足够的权限来删除由 RunAsUser 或 RunAsGroup 中定义的任何范围写入容器中的文件。我建议您对用户和组使用 MustRunAsNonRoot 以避免所描述的情况。
作为最佳实践，如果您在 Kubernetes 集群上运行多个应用程序，则每个应用程序都应运行到自己的命名空间中以避免名称冲突，并且应为每个应用程序使用不同的 uid 和 MCS 标签。此外，建议所有容器以单个非 root 用户身份运行。当使用节点和容器的安全上下文时，here 描述的用例提供了其中一些注意事项。
在此链接中，您可以找到有关Pod Security Policy 的更多详细信息
【讨论】：
在这种情况下，如果 pod 的安全上下文未设置为“特权”，那么容器将不会获得 root 特权。如果您是集群管理员，您可以使用 Pod 安全策略来限制特权容器的使用。
在这个document 中，您将找到操作容器的 7 个最佳实践，这些实践也适用于 Docker。基本上，您必须避免使用特权容器以避免所描述的场景。
【讨论】：