强制实施 Pod 安全性标准

    特性状态：

    Pod 安全性准入控制器 尝试替换已被废弃的 PodSecurityPolicies。

    完全未经配置的名字空间应该被视为集群安全模型中的重大缺陷。 我们建议花一些时间来分析在每个名字空间中执行的负载的类型， 并通过引用 Pod 安全性标准来确定每个负载的合适级别。 未设置标签的名字空间应该视为尚未被评估。

    针对所有名字空间中的所有负载都具有相同的安全性需求的场景， 我们提供了一个 用来展示如何批量应用 Pod 安全性标签。

    • 允许 privileged 负载的名字空间需要建立并实施适当的访问控制机制。
    • 对于运行在特权宽松的名字空间中的负载，需要维护其独特安全性需求的文档。 如果可能的话，要考虑如何进一步约束这些需求。

    Pod 安全性标准准入控制器的 audit 和 warn 模式（mode） 能够在不影响现有负载的前提下，让该控制器更方便地收集关于 Pod 的重要的安全信息。

    针对所有名字空间启用这些模式是一种好的实践，将它们设置为你最终打算 的 期望的 级别和版本。这一阶段中所生成的警告和审计注解信息可以帮助你到达这一状态。 如果你期望负载的作者能够作出变更以便适应期望的级别，可以启用 warn 模式。 如果你希望使用审计日志了监控和驱动变更，以便负载能够适应期望的级别，可以启用 audit 模式。

    当你将 enforce 模式设置为期望的取值时，这些模式在不同的场合下仍然是有用的：

    • 在将 enforce 锁定到特定的非最新版本的名字空间中，将 audit 和 warn 模式设置为 enforce 一样的级别而非 版本， 这样可以方便看到之前版本所允许但当前最佳实践中被禁止的设置。

    第三方替代方案

    说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

    采用 内置的 方案（例如 PodSecurity 准入控制器）还是第三方工具， 这一决策完全取决于你自己的情况。在评估任何解决方案时，对供应链的信任都是至关重要的。 最终，使用前述方案中的 任何 一种都好过放任自流。

    本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅了解更多细节。

    在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读内容指南。