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 不同。

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

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

我们为什么需要 PodSecurityPolicy？

在 Kubernetes 中，我们定义了 Deployment、StatefulSet 和 Service 等资源，它们代表了软件应用程序的构建块。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 维护者跟踪会议视频

如今，您不再局限于部署 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 的使用相对简单，只有少量策略并且每个命名空间都直接绑定到 ServiceAccount，那么您可能会发现 PSP 替换策略非常适合您的需求。将您的 PSP 与 Kubernetes Pod 安全标准进行比较，以了解您可以在哪些地方使用受限、基线和特权策略。请关注或贡献 KEP 和后续开发，并在 PSP 替换策略的 Alpha 版本可用时进行试用。

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

我们致力于将 Kubernetes 打造成我们所能做到的最好的容器编排工具，有时这意味着我们需要移除长期存在的功能，为更好的事物腾出空间。当这种情况发生时，Kubernetes 弃用策略确保您有充足的时间来规划下一步行动。对于 PodSecurityPolicy，有几种选项可满足一系列需求和用例。现在就开始为 PSP 的最终移除做计划，并请考虑为它的替代品做出贡献！祝您安全愉快！

致谢：一个优秀的团队才能打造出优秀的软件。感谢所有为 PSP 替换工作做出贡献的人，尤其（按字母顺序排列）是 Tim Allclair、Ian Coldwater 和 Jordan Liggitt。与大家一起完成这项工作是我的荣幸。

• ←上一篇
• 下一篇→