弃用PodSecurityPolicy：过去、现在和未来
作者：Tabitha Sable（Kubernetes SIG Security）
PodSecurityPolicy（PSP）在 Kubernetes 1.21 中将被弃用，1.21 版本在这周晚些时候发布。这就开始了移除它的倒计时，但不会改变其他任何东西。在被完全删除之前，PodSecurityPolicy 将继续在多个版本中提供完整的功能。与此同时，我们正在开发一个 PSP 的替代品，它将更容易和可持续地覆盖关键的用例。
Pod Security Policies 是什么？我们为什么需要他们？他们为什么要离开，接下来会发生什么？这对你有什么影响？当我们准备告别 PSP 时，这些关键的问题浮现在我们的脑海中，所以让我们一起来讨论一下。我们将从 Kubernetes 如何删除特性的概述开始。
在 Kubernetes 中，弃用是什么意思？
每当 Kubernetes 特性要消失时，我们弃用策略[1]就是我们的指南。首先，该特性被标记为已弃用，然后经过足够的时间，它最终可以被删除。
Kubernetes 1.21 启动 PodSecurityPolicy 的弃用过程。与所有已弃用的特性一样，PodSecurityPolicy 将在今后的几个版本中继续发挥完全的功能。目前的计划是在 1.25 版本中将 PSP 从 Kubernetes 中移除。
在此之前，PSP 仍然是 PSP。在至少一年的时间里，最新的 Kubernetes 版本仍然会支持 PSP，而在 PSP 完全消失于 Kubernetes 版本支持之前，将会有近两年的时间。
PodSecurityPolicy 是什么？
PodSecurityPolicy[2]是一个内置的准入控制器[3]，它允许集群管理员控制 Pod 规范的安全敏感方面。
首先，在集群中创建一个或多个 PodSecurityPolicy 资源，以定义 Pod 必须满足的需求。然后，创建 RBAC 规则来控制哪个 PodSecurityPolicy 应用于给定的 pod。如果一个 pod 满足其 PSP 的要求，它将像往常一样被允许进入集群。在某些情况下，PSP 也可以修改 Pod 字段，有效地为这些字段创建新的默认值。如果一个 Pod 不符合 PSP 的要求，它将被拒绝，并且不能运行。
关于 PodSecurityPolicy 还有一点需要了解：它与PodSecurityContext[4]是不同的。
作为 Pod 规范的一部分，PodSecurityContext（及其每个容器对应的 SecurityContext）是为 Pod 指定许多与安全相关设置的字段的集合。安全上下文向 kubelet 和容器运行时指示 Pod 实际应该如何运行。相反，PodSecurityPolicy 只约束（或默认）可能在安全上下文中设置的值。
PSP 的弃用不会以任何方式影响到 PodSecurityContext。
为什么我们需要 PodSecurityPolicy？
在 Kubernetes 中，我们定义了资源，如 Deployment、StatefulSet 和 Service 代表软件应用程序的构建块。Kubernetes 集群中的各种控制器对这些资源做出反应，创建更多的 Kubernetes 资源或配置一些软件或硬件来实现我们的目标。
在大多数 Kubernetes 集群中，RBAC（基于角色的访问控制）规则[5]控制对这些资源的访问。list、get、create、edit 和 delete 是 RBAC 关心的 API 操作，但 RBAC 不考虑将什么设置放入它控制的资源中。例如，Pod 几乎可以是任何东西，从简单的 web 服务器到提供对底层服务器节点和所有数据的完全访问的特权命令提示符。这对 RBAC 来说都是一样的：一个 Pod 就是一个 Pod 就是一个 Pod。
要控制集群中定义的资源中允许的设置类型，除了 RBAC 之外，还需要准入控制。自从 Kubernetes 1.3 以来，PodSecurityPolicy 已经成为了实现与安全相关的 Pod 字段的内置方法。使用 PodSecurityPolicy，你可以防止“create Pod”自动表示“在每个集群节点上的根节点”，而不需要部署额外的外部准入控制器。
为什么 PodSecurityPolicy 会消失？
自从 PodSecurityPolicy 首次引入以来，我们已经意识到 PSP 存在一些严重的可用性问题，如果不进行突破性的更改，这些问题是无法解决的。
PSP 应用于 Pod 的方式已经被证明让几乎所有试图使用它们的人感到困惑。它很容易意外地授予比预期更广泛的权限，并且很难检查哪个 PSP（s）应用在给定的情况下。“更改 Pod 默认值”功能很方便，但只支持某些 Pod 设置，而且它们何时适用于或不适用于你的 Pod 并不明显。如果没有“dry run”或审计模式，将 PSP 安全改造到现有集群是不切实际的，而且 PSP 不可能在默认情况下启用。
有关这些和其他 PSP 困难的更多信息，请查看 SIG Auth 在 KubeCon NA 2019 维护者 Track session 视频：
今天，你不再局限于部署 PSP 或编写自己的自定义准入控制器。有几个外部的准入控制器，它们结合了从 PSP 中学到的经验，提供了更好的用户体验。K-Rail[6]、Kyverno[7]和OPA/Gatekeeper[8]都很有名，并且都有自己的粉丝。
虽然现在有其他好的选择，但我们相信，为用户提供一个内置的准入控制器仍然是有价值的。带着这个想法，我们从 PSP 中学到的教训中得到启发，开始着手下一步的工作。
接下来是什么？
Kubernetes SIG Security、SIG Auth 和其他社区成员的不同集合已经一起工作了几个月，以确保接下来将要发生的事情将是令人惊叹的。我们已经开发了一个 Kubernetes 增强方案（KEP 2579[9]）和一个新功能的原型，目前暂称为“PSP 替换策略（PSP Replacement Policy）”。我们的目标是在 Kubernetes 1.22 中发布 Alpha 版本。
PSP 替换策略始于这样一种认识：既然已经有了一个强大的外部准入控制器生态系统，那么 PSP 的替换并不需要对所有人都适用。与外部 webhook 相比，内置的准入控制器的关键优势是部署和采用的简单性，因此我们将重点放在如何最好地利用这一优势上。
PSP 替换策略设计得尽可能简单，同时提供足够的灵活性，在大规模生产中真正有用。它具有软推出特性，可以将其改造为现有集群，并且具有足够的可配置性，最终可以在默认情况下激活它。它可以部分或全部停用，以便与高级用例中的外部接纳控制器共存。
这对你来说意味着什么？
这对你来说意味着什么取决于你目前的 PSP 情况。如果你已经在使用 PSP，你有足够的时间来计划你的下一步行动。请检阅 PSP 替换策略，并考虑它是否适合你的使用情况。
如果你正在大量使用 PSP 的灵活性和复杂的绑定规则，你可能会发现简单的 PSP 替换政策太有限。用来年来评估生态系统中的其他准入控制器选择。有一些资源可以简化这种转换，例如Gatekeeper 策略库[10]。
如果你使用 PSP 是相对简单的，在每个命名空间有一些策略和直接绑定到服务帐户，你可能会发现 PSP 替换策略很适合你的需要。将你的 PSP 与 Kubernetes Pod 安全标准[11]进行比较，以了解你将能够在何处使用 Restricted、Baseline 和 Privileged 策略。请关注或参与 KEP 及后续开发，并在 PSP 替换策略可用时尝试 Alpha 版本。
如果你只是开始 PSP 之旅，则可以通过简化流程来节省时间和精力。你可以使用 Pod 安全标准的 PSP 来近似估算 PSP 替换策略的功能。如果通过将 Baseline 策略或 Restricted 策略绑定到 system:serviceaccounts 组来设置群集默认值，然后使用 ServiceAccount 绑定[12]根据需要在某些命名空间中提供更宽松的策略，则可以避免许多 PSP 陷阱，并且很容易迁移到 PSP 替换策略。如果你的需求远不止于此，那么你最好花更多的精力来采用上面提到的功能更强大的外部准入控制器之一。
总结
我们致力于使 Kubernetes 成为最好的容器编排工具，有时这意味着我们需要删除一些长期存在的特性，为更好的东西腾出空间。当这种情况发生时，Kubernetes 弃用策略会确保你有足够的时间来计划下一步行动。对于 PodSecurityPolicy，有几个选项可以满足各种需求和用例。现在就开始计划 PSP 的最终移除，并请考虑为其替换贡献力量！Happy securing！
鸣谢
优秀的团队才能制作出优秀的软件。感谢所有为 PSP 替换工作做出贡献的人，特别是（按字母顺序排列）Tim Allclair、 Ian Coldwater 和 Jordan Liggitt。很高兴能和你们一起工作。
参考资料
弃用策略: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
[2]PodSecurityPolicy: https://kubernetes.io/docs/concepts/policy/pod-security-policy/
[3]准入控制器: https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/
[4]PodSecurityContext: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context
[5]规则: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole
[6]K-Rail: https://github.com/cruise-automation/k-rail
[7]Kyverno: https://github.com/kyverno/kyverno/
[8]OPA/Gatekeeper: https://github.com/open-policy-agent/gatekeeper/
[9]KEP 2579: https://github.com/kubernetes/enhancements/issues/2579
[10]Gatekeeper 策略库: https://github.com/open-policy-agent/gatekeeper-library
[11]Pod 安全标准: https://kubernetes.io/docs/concepts/security/pod-security-standards/
[12]使用 ServiceAccount 绑定: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#run-another-pod
点击【阅读原文】阅读网站原文。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。