强制实施 Pod 安全标准

本页面概述了在实施 Pod 安全标准 方面的最佳实践。

使用内置的 Pod 安全准入控制器

功能状态: Kubernetes v1.25 [稳定]

Pod 安全准入控制器 旨在取代已弃用的 Pod 安全策略。

配置所有集群命名空间

完全没有配置的命名空间应该被视为集群安全模型中的重大漏洞。我们建议花时间分析每个命名空间中发生的各种工作负载类型,并参考 Pod 安全标准,为每个工作负载确定适当的级别。未标记的命名空间应该只表明它们尚未经过评估。

在所有命名空间中的所有工作负载具有相同安全要求的情况下,我们提供了一个 示例,说明如何批量应用 Pod 安全标签。

采用最小特权原则

在理想情况下,每个命名空间中的每个 Pod 都应该满足 restricted 策略的要求。但是,这既不可能也不实用,因为一些工作负载出于正当理由需要提升的权限。

  • 允许 privileged 工作负载的命名空间应该建立和执行适当的访问控制。
  • 对于在这些允许性命名空间中运行的工作负载,请维护其独特安全要求的文档。如果可能,请考虑如何进一步限制这些要求。

采用多模式策略

Pod 安全标准准入控制器的 auditwarn 模式使您可以轻松地收集有关 Pod 的重要安全见解,而不会破坏现有工作负载。

最好为所有命名空间启用这些模式,将它们设置为最终要 enforce期望级别和版本。在此阶段生成的警告和审核注释可以指导您进入该状态。如果您期望工作负载作者进行更改以适应期望级别,请启用 warn 模式。如果您期望使用审核日志监控/驱动更改以适应期望级别,请启用 audit 模式。

当您将 enforce 模式设置为期望值时,这些模式在以下几种情况下仍然很有用

  • 通过将 warn 设置为与 enforce 相同的级别,客户端在尝试创建不通过验证的 Pod(或具有 Pod 模板的资源)时会收到警告。这将帮助他们更新这些资源以使其符合要求。
  • 在将 enforce 固定到特定非最新版本的命名空间中,将 auditwarn 模式设置与 enforce 相同的级别,但设置为 latest 版本,可以了解以前版本允许但在当前最佳实践中不允许的设置。

第三方替代方案

Kubernetes 生态系统中正在开发其他用于实施安全配置文件的替代方案

使用内置解决方案(例如 Pod 安全准入控制器)与第三方工具之间的决策完全取决于您自己的情况。在评估任何解决方案时,供应链的信任至关重要。最终,使用上述任何一种方法都比什么都不做要好。

本页面上的项目是指提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关更多详细信息,请参见 CNCF 网站指南

在提出添加额外第三方链接的更改之前,您应该阅读 内容指南

最后修改时间:2022 年 9 月 22 日 下午 3:12 PST: 将 Pod 安全插件的功能状态提升为稳定 (1ab76fba82)