Pod 安全策略弃用：过去、现在与未来

PodSecurityPolicy (PSP) 在 Kubernetes 1.21 中被弃用，该版本将于本周晚些时候发布。这标志着其移除倒计时的开始，但不会改变其他任何东西。PodSecurityPolicy 在完全移除之前将在接下来的几个版本中继续完全可用。与此同时，我们正在开发 PSP 的替代方案，以更轻松和可持续的方式涵盖关键用例。

什么是 PodSecurityPolicy？我们为什么需要它们？为什么它们要被移除，下一步是什么？这会如何影响你？当我们准备告别 PSP 时，这些关键问题浮现在脑海中，所以让我们一起来探讨。我们将首先概述 Kubernetes 中的功能是如何被移除的。

弃用在 Kubernetes 中意味着什么？

每当一个 Kubernetes 功能被设定要移除时，我们的弃用策略就是我们的指引。首先该功能会被标记为弃用，然后经过足够的时间后，最终会被移除。

Kubernetes 1.21 开始了 PodSecurityPolicy 的弃用过程。与所有功能弃用一样，PodSecurityPolicy 将在接下来的几个版本中继续完全可用。目前的计划是在 1.25 版本中从 Kubernetes 中移除 PSP。

在此之前，PSP 仍然是 PSP。最新的 Kubernetes 版本将至少有一年继续支持 PSP，并且在近两年内，PSP 将完全退出所有受支持的 Kubernetes 版本。

什么是 PodSecurityPolicy？

PodSecurityPolicy 是一个内置的准入控制器，它允许集群管理员控制 Pod 规范中与安全相关的方面。

首先，在集群中创建一个或多个 PodSecurityPolicy 资源来定义 Pod 必须满足的要求。然后，创建 RBAC 规则来控制哪个 PodSecurityPolicy 适用于特定的 Pod。如果一个 Pod 满足其 PSP 的要求，它将照常被准入集群。在某些情况下，PSP 还可以修改 Pod 字段，有效地为这些字段创建新的默认值。如果一个 Pod 不满足 PSP 的要求，它将被拒绝，无法运行。

关于 PodSecurityPolicy 还有一件重要的事情需要知道：它与PodSecurityContext不同。

PodSecurityContext（以及其容器级别的对应项 SecurityContext）作为 Pod 规范的一部分，是指定 Pod 许多安全相关设置的字段集合。安全上下文指示 kubelet 和容器运行时如何实际运行 Pod。相比之下，PodSecurityPolicy 只限制（或默认）可以在安全上下文上设置的值。

PSP 的弃用不会以任何方式影响 PodSecurityContext。

我们为什么需要 PodSecurityPolicy？

在 Kubernetes 中，我们定义了诸如 Deployments、StatefulSets 和 Services 等资源，它们代表了软件应用程序的构建块。Kubernetes 集群中的各种控制器对这些资源做出反应，创建进一步的 Kubernetes 资源或配置某些软件或硬件以实现我们的目标。

在大多数 Kubernetes 集群中，RBAC（基于角色的访问控制）规则控制对这些资源的访问。list、get、create、edit 和 delete 是 RBAC 关心的 API 操作类型，但 RBAC 不会考虑在其控制的资源中设置了什么参数。例如，一个 Pod 几乎可以是任何东西，从一个简单的 Web 服务器到一个提供对底层服务器节点和所有数据完全访问权限的特权命令提示符。对于 RBAC 来说，它们都是一样的：Pod 就是 Pod 就是 Pod。

为了控制你的集群中定义的资源允许哪些类型的设置，除了 RBAC 之外，你还需要准入控制。自 Kubernetes 1.3 起，PodSecurityPolicy 一直是针对安全相关的 Pod 字段执行此操作的内置方式。使用 PodSecurityPolicy，你可以防止“创建 Pod”自动意味着“在每个集群节点上获得 root 权限”，而无需部署额外的外部准入控制器。

为什么 PodSecurityPolicy 要被移除？

自 PodSecurityPolicy 首次引入以来的这些年里，我们意识到 PSP 存在一些严重的可用性问题，这些问题必须通过破坏性变更才能解决。

PSP 应用于 Pod 的方式已被证明让几乎所有尝试使用它的人感到困惑。很容易意外地授予比预期更广泛的权限，并且难以检查在特定情况下哪个（或哪些）PSP 生效。 “更改 Pod 默认值”功能可能很方便，但仅支持某些 Pod 设置，并且不清楚它们何时会或不会应用于你的 Pod。没有“空运行”或审计模式，安全地将 PSP 应用于现有集群是不切实际的，并且 PSP 永远不可能默认启用。

有关这些和其他 PSP 困难的更多信息，请查看 SIG Auth 在 KubeCon NA 2019 Maintainer Track 会议上的视频。

如今，你不必仅限于部署 PSP 或编写自己的自定义准入控制器。有几个外部准入控制器可用，它们结合了从 PSP 中学到的经验，提供了更好的用户体验。K-Rail、Kyverno 和 OPA/Gatekeeper 都很有名，并且各有拥趸。

尽管现在有其他不错的选择，但我们相信拥有一个内置的准入控制器作为用户的选择仍然有价值。考虑到这一点，我们受 PSP 经验教训的启发，着手构建下一步。

下一步是什么？

Kubernetes SIG Security、SIG Auth 以及其他众多社区成员数月来一直共同努力，以确保接下来的工作将非常出色。我们已经开发了一个 Kubernetes 增强提案（KEP 2579）和一个新功能的原型，目前暂时命名为“PSP 替代策略”（PSP Replacement Policy）。我们计划在 Kubernetes 1.22 中发布 Alpha 版本。

PSP 替代策略始于一个认识：既然已经存在一个强大的外部准入控制器生态系统，PSP 的替代方案就不必面面俱到。内置准入控制器相对于外部 webhook 的关键优势在于部署和采用的简便性，因此我们专注于如何最好地利用这一优势。

PSP 替代策略旨在在实践上尽可能简单，同时提供足够的灵活性以在大规模生产中真正有用。它具有软发布功能，可以将其应用于现有集群，并且足够可配置，最终可以默认激活。它可以部分或完全停用，以便与外部准入控制器共存以应对高级用例。

这对你意味着什么？

这对你意味着什么取决于你当前的 PSP 使用情况。如果你已经在​​使用 PSP，你有充足的时间来规划下一步。请查看 PSP 替代策略 KEP，并考虑它如何适合你的用例。

如果你广泛利用 PSP 的灵活性，使用了大量的 PSP 和复杂的绑定规则，你可能会发现 PSP 替代策略过于简单而受到限制。利用未来一年评估生态系统中的其他准入控制器选项。有一些资源可以帮助简化这种过渡，例如Gatekeeper Policy Library。

如果你对 PSP 的使用相对简单，只有少量策略并直接绑定到每个命名空间中的服务账号，你可能会发现 PSP 替代策略很适合你的需求。将你的 PSP 与 Kubernetes Pod Security Standards 进行比较，以了解你在哪些地方可以使用 Restricted、Baseline 和 Privileged 策略。请关注或贡献于 KEP 和后续开发，并在 PSP 替代策略的 Alpha 版本可用时进行尝试。

如果你刚刚开始你的 PSP 之旅，通过保持简单，你将节省时间和精力。今天，你可以通过使用 Pod Security Standards 的 PSP 来近似 PSP 替代策略的功能。如果你通过将 Baseline 或 Restricted 策略绑定到 system:serviceaccounts 组来设置集群默认值，然后使用 ServiceAccount 绑定在某些命名空间中根据需要提供更宽松的策略，你将避免许多 PSP 的陷阱，并且可以轻松迁移到 PSP 替代策略。如果你的需求比这复杂得多，你投入的精力最好用于采用上面提到的功能更全面的外部准入控制器之一。

我们致力于将 Kubernetes 打造成最好的容器编排工具。有时，这意味着我们需要移除一些长期存在的功能，以便为更好的未来版本腾出空间。当这种情况发生时，Kubernetes 的弃用策略确保您有充足的时间来规划下一步行动。对于 PodSecurityPolicy，有几种可用的选项，以满足不同的需求和用例。现在就开始为 PSP 最终移除做提前规划吧，并请考虑为其替代方案做出贡献！祝您安全无虞！

致谢： 一流的软件离不开一流的团队。感谢所有为 PSP 替代方案工作做出贡献的人，特别是（按字母顺序排列）Tim Allclair、Ian Coldwater 和 Jordan Liggitt。与大家一起工作非常愉快。

• ←上一页
• 下一页→