强制实施 Pod 安全标准

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

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

Pod 安全准入控制器旨在替代已弃用的 PodSecurityPolicies。

配置所有集群命名空间

对于没有任何配置的命名空间，应将其视为集群安全模型中的显著漏洞。我们建议花时间分析每个命名空间中运行的工作负载类型，并通过参考 Pod 安全标准，为它们中的每一个决定适当的级别。未标注的命名空间仅表示它们尚未经过评估。

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

遵循最小权限原则

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

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

采用多模式策略

Pod 安全标准准入控制器的 audit（审计）和 warn（警告）模式使您能够轻松收集有关 Pod 的重要安全见解，而不会破坏现有工作负载。

为所有命名空间启用这些模式是一个好的实践，将其设置为您最终希望 enforce（强制）的期望级别和版本。在此阶段生成的警告和审计注释可以引导您达到该状态。如果您希望工作负载所有者进行更改以符合期望级别，请启用 warn 模式。如果您希望使用审计日志来监控/推动更改以符合期望级别，请启用 audit 模式。

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

• 通过将 warn 设置为与 enforce 相同的级别，客户端在尝试创建未通过验证的 Pod（或具有 Pod 模板的资源）时将收到警告。这将帮助他们更新这些资源以使其合规。
• 在将 enforce 固定为特定非最新版本的命名空间中，将 audit 和 warn 模式设置为与 enforce 相同的级别，但版本设置为 latest，可以洞察那些在以前版本中允许但根据当前最佳实践不再允许的设置。

第三方替代方案

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

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

选择内置解决方案（例如 PodSecurity 准入控制器）还是第三方工具，完全取决于您自己的情况。在评估任何解决方案时，对供应链的信任至关重要。归根结底，使用上述任何方法都比什么都不做要好。