PodSecurityPolicy 弃用：过去、现在和未来

PodSecurityPolicy (PSP) 将在 Kubernetes 1.21 中被弃用，该版本将于本周晚些时候发布。这开始了倒计时，但不会改变其他任何事情。PodSecurityPolicy 将在被完全删除之前继续保持完全功能，持续多个版本。与此同时，我们正在开发 PSP 的替代方案，该方案可以更轻松、可持续地涵盖关键用例。

什么是 Pod 安全策略？为什么我们需要它们？为什么它们会被淘汰，下一步是什么？这对你有什么影响？当我们准备告别 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 不同。

作为 Pod 规范的一部分，PodSecurityContext（及其每个容器的对应项 SecurityContext）是指定 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。

要控制在集群中定义的资源中允许哪种设置，除了 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 维护者主题会议视频

如今，你不仅限于部署 PSP 或编写自己的自定义准入控制器。有几个外部准入控制器可供选择，它们结合了从 PSP 中吸取的教训，以提供更好的用户体验。K-Rail、Kyverno 和 OPA/Gatekeeper 都是众所周知的，并且每个都有自己的粉丝。

尽管现在还有其他不错的选择，但我们认为仍然有价值让内置的准入控制器作为用户的选择。考虑到这一点，我们将转向构建下一步，并从 PSP 中吸取的教训中获得启发。

下一步是什么？

Kubernetes SIG Security、SIG Auth 和其他社区成员的多样化集合已经合作了数月，以确保下一步的发展是令人惊叹的。我们已经开发了一个 Kubernetes 增强提案 (KEP 2579) 和一个新功能的原型，目前被临时命名为“PSP 替代策略”。我们的目标是在 Kubernetes 1.22 中发布 Alpha 版本。

PSP 替代策略始于这样一个认识：由于已经存在一个强大的外部准入控制器生态系统，因此 PSP 的替代方案不需要对所有人来说都是万能的。与外部 Webhook 相比，内置的准入控制器的主要优势是部署和采用的简单性，因此我们专注于如何最好地利用该优势。

PSP 替代策略旨在尽可能简单，同时提供足够的灵活性，以便在生产中大规模使用。它具有软推出功能，可以将其改装到现有集群，并且具有足够的配置能力，使其最终可以默认处于活动状态。它可以部分或完全停用，以便与外部准入控制器共存以用于高级用例。

这对你来说意味着什么？

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

如果你正在广泛使用 PSP 的灵活性，其中包含许多 PSP 和复杂的绑定规则，你可能会发现 PSP 替代策略的简单性过于局限。利用明年时间来评估生态系统中的其他准入控制器选择。有一些资源可以简化此过渡，例如 Gatekeeper 策略库。

如果您的 PSP 使用相对简单，只有少量策略，并且在每个命名空间中与服务帐户的绑定也比较直接，那么您可能会发现 PSP 替换策略很适合您的需求。请将您的 PSP 与 Kubernetes Pod 安全标准 进行比较，以了解您可以在哪些地方使用受限（Restricted）、基线（Baseline）和特权（Privileged）策略。请持续关注并参与 KEP 及后续开发，并在 PSP 替换策略的 Alpha 版本可用时进行尝试。

如果您刚刚开始使用 PSP，保持简单将为您节省时间和精力。您可以通过使用 Pod 安全标准的 PSP 来近似实现 PSP 替换策略的功能。如果您通过将基线或受限策略绑定到 system:serviceaccounts 组来设置集群默认值，然后在某些命名空间中根据需要通过 使用 ServiceAccount 绑定提供更宽松的策略，您将避免许多 PSP 的陷阱，并且可以轻松迁移到 PSP 替换策略。如果您的需求比这复杂得多，您可能最好选择采用上述更完善的外部准入控制器之一。

我们致力于使 Kubernetes 成为我们所能做到的最好的容器编排工具，有时这意味着我们需要移除一些长期存在的功能，为更好的未来腾出空间。当这种情况发生时，Kubernetes 的弃用政策会确保您有充足的时间来计划下一步行动。就 PodSecurityPolicy 而言，有多种选项可供选择，以满足各种需求和用例。现在就开始为 PSP 最终移除做计划，并请考虑为它的替换做出贡献！祝您安全愉快！

致谢：创造出色的软件需要一个出色的团队。感谢所有为 PSP 替换工作做出贡献的人，特别是（按字母顺序排列）Tim Allclair、Ian Coldwater 和 Jordan Liggitt。很高兴能和大家一起完成这项工作。

• ←上一页
下一页→