PodSecurityPolicy：历史背景
PodSecurityPolicy (PSP) 准入控制器已从 Kubernetes v1.25 中移除。其弃用已在 Kubernetes v1.21 版本发布的博文中 PodSecurityPolicy 弃用：过去、现在和未来 中宣布并详细说明。
本文旨在提供有关 PSP 的诞生和演变的历史背景，解释为什么该功能从未达到稳定版本，并说明为什么它被移除并由 Pod 安全准入控制所取代。
PodSecurityPolicy 与其他专门的准入控制插件一样，以内置策略 API 的形式，对有关 Pod 安全设置的特定字段提供了细粒度的权限。它承认集群管理员和集群用户通常不是同一批人，并且以 Pod 或任何将创建 Pod 的资源的形式创建工作负载不应等同于“集群上的 root”。它还可以通过配置更安全的默认设置并通过解耦低级 Linux 安全决策与部署过程来鼓励最佳实践。
PodSecurityPolicy 的诞生
PodSecurityPolicy 源于 OpenShift 的 SecurityContextConstraints (SCC)，该功能甚至在 Kubernetes 1.0 之前就已存在于 Red Hat OpenShift Container Platform 的最早版本中。PSP 是 SCC 的精简版本。
PodSecurityPolicy 的创建起源很难追踪，特别是因为它主要是在 Kubernetes 增强提案 (KEP) 流程之前添加的，当时设计提案仍然是一种形式。事实上，最终的 设计提案的存档仍然可用。尽管如此，在第一个拉取请求合并后，还是创建了一个 KEP 问题编号五。
在添加创建 PSP 的第一段代码之前，两个主要的拉取请求被合并到了 Kubernetes 中，一个是定义了 Pod 容器新字段的 SecurityContext 子资源，另一个是 ServiceAccount API 的首次迭代。
Kubernetes 1.0 于 2015 年 7 月 10 日发布，除了一个 alpha 质量的 SecurityContextDeny 准入插件（当时称为 scdeny）之外，没有任何限制工作负载的安全上下文和敏感选项的机制。SecurityContextDeny 插件今天仍然存在于 Kubernetes 中（作为 alpha 功能），并创建一个准入控制器，该控制器阻止在安全上下文中使用某些字段。
PodSecurityPolicy 的根源是通过 关于安全策略的第一个拉取请求添加的，该请求添加了包含基于 SCC（安全上下文约束）的新 PSP 对象的设计提案。这是一个长达九个月的讨论，来回讨论了 OpenShift 的 SCC，多次重新调整，并重命名为 PodSecurityPolicy，最终于 2016 年 2 月进入了上游 Kubernetes。现在 PSP 对象已经创建，下一步是添加一个可以强制执行这些策略的准入控制器。第一步是添加准入 而不考虑用户或组。为了跟踪进度，添加了一个 使 PodSecurityPolicy 进入可用状态的问题，并且在 2016 年 5 月的 名为 PSP 准入的拉取请求中合并了第一个版本的准入控制器。大约两个月后，Kubernetes 1.3 发布。
以下时间线回顾了 PodSecurityPolicy 及其准入控制器的诞生过程中的主要拉取请求，并以 1.0 和 1.3 版本为参考点。
之后，通过添加最初被搁置的内容来增强 PSP 准入控制器。授权机制于 2016 年 11 月初合并，允许管理员在集群中使用多个策略，为不同类型的用户授予不同级别的访问权限。之后，于 2017 年 10 月合并的 拉取请求修复了 一个设计问题，该问题是关于在变异和字母顺序之间对 PodSecurityPolicy 进行排序的问题，并继续构建我们所知的 PSP 准入。此后，进行了许多改进和修复，以构建最近 Kubernetes 版本的 PodSecurityPolicy 功能。
Pod 安全准入的兴起
尽管 PodSecurityPolicy 试图解决至关重要的问题，但它仍然存在一些重大缺陷
- 有缺陷的授权模型 - 如果用户对允许该 Pod 的 PSP 具有 use 动词，或者 Pod 的服务帐户对允许的 PSP 具有 use 权限，则用户可以创建 Pod。
- 难以推广 - PSP 默认拒绝。也就是说，在没有策略的情况下，所有 Pod 都会被拒绝。这主要意味着它不能默认启用，用户必须在启用该功能之前为所有工作负载添加 PSP，因此没有提供审核模式来发现哪些 Pod 不会被新策略允许。选择加入模式还导致测试覆盖率不足，并且由于跨功能不兼容而导致频繁中断。而且与 RBAC 不同，没有将 PSP 清单与项目一起发布的强大文化。
- 不一致的无界 API - API 随着许多利基用例的请求而增长，例如标签、调度、细粒度的卷控制等，导致了很多不一致。它与弱优先级模型的可组合性较差，导致意外的变异优先级。这使得将 PSP 与其他第三方准入控制器组合起来非常困难。
- 需要安全知识 - 有效使用仍然需要了解 Linux 安全原语。例如 MustRunAsNonRoot + AllowPrivilegeEscalation。
PodSecurityPolicy 的经验表明，大多数用户关心的是两到三个策略，这导致了 Pod 安全标准 的创建，该标准定义了三个策略
- 特权 - 无限制策略。
- 基线 - 最低限制策略，允许默认 Pod 配置。
- 受限 - 安全最佳实践策略。
作为 PSP 的替代方案，新的 Pod 安全准入是一个内置的、稳定的 Kubernetes v1.25 的准入插件，用于在命名空间级别强制执行这些标准。它使得在没有深入安全知识的情况下更容易强制执行基本的 Pod 安全性。对于更复杂的用例，您可能需要一个可以轻松与 Pod 安全准入相结合的第三方解决方案。
接下来是什么
有关 SIG Auth 流程的更多详细信息，包括 PodSecurityPolicy 的移除和 Pod 安全准入的创建，请参阅 KubeCon NA 2019 上的 SIG auth 更新和 PodSecurityPolicy 替代方案：过去、现在和未来，这是在 KubeCon NA 2021 上的演讲记录。
特别是关于 PSP 的移除，PodSecurityPolicy 弃用：过去、现在和未来 博客文章仍然准确。
对于新的 Pod 安全准入，文档可用。此外，博客文章 Kubernetes 1.23：Pod 安全升级为 Beta 以及 KubeCon EU 2022 的演讲 Pod 安全入门指南 都提供了很棒的动手教程供学习。