强制执行 Pod 安全标准

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

使用内置的 Pod Security 准入控制器

特性状态: Kubernetes v1.25 [稳定]

Pod Security 准入控制器旨在取代已弃用的 PodSecurityPolicies。

配置所有集群命名空间

没有任何配置的命名空间应被视为集群安全模型中的重要空白。我们建议花时间分析每个命名空间中存在的各种工作负载类型,并参考 Pod 安全标准,为每个命名空间确定适当的级别。未标记的命名空间仅表示它们尚未被评估。

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

遵循最小权限原则

在理想情况下,每个命名空间中的每个 Pod 都应满足受限策略的要求。然而,这既不可能也不切实际,因为某些工作负载出于合理原因需要提升权限。

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

采用多模式策略

Pod 安全标准的准入控制器的 audit(审计)和 warn(警告)模式使得收集关于 Pod 的重要安全洞察变得容易,而不会破坏现有工作负载。

最佳实践是为所有命名空间启用这些模式,将它们设置为您最终想要enforce(强制)执行的理想级别和版本。在此阶段生成的警告和审计注解可以指导您达到该状态。如果您希望工作负载作者进行更改以符合理想级别,请启用 warn 模式。如果您希望使用审计日志来监控/推动更改以符合理想级别,请启用 audit 模式。

当您将 enforce 模式设置为理想值时,这些模式仍然可以通过几种不同的方式发挥作用:

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

第三方替代方案

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

选择内置解决方案(例如 PodSecurity 准入控制器)还是第三方工具完全取决于您自身的情况。在评估任何解决方案时,信任您的供应链至关重要。最终,使用上述任何方法总比什么都不做要好。

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

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

最后修改于 2022 年 9 月 22 日太平洋标准时间下午 3:12:将 Pod 安全插件的特性状态升级为稳定 (1ab76fba82)