实施 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.

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