目录

什么是 PodSecurityPolicy？

以前为什么需要 PodSecurityPolicy？

现在为什么 PodSecurityPolicy 要消失？

什么是 PodSecurityPolicy？

PodSecurityPolicy 是一个内置的准入控制器， 允许集群管理员控制 Pod 规约中涉及安全的敏感内容。

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

关于 PodSecurityPolicy，还需要了解：它与 PodSecurityContext 不同。

作为 Pod 规约的一部分，PodSecurityContext（及其每个容器对应的 SecurityContext） 是一组字段的集合，这些字段为 Pod 指定了与安全相关的许多设置。 安全上下文指示 kubelet 和容器运行时究竟应该如何运行 Pod。 相反，PodSecurityPolicy 仅约束可能在安全上下文中设置的值（或设置默认值）。

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

以前为什么需要 PodSecurityPolicy？

在 Kubernetes 中，我们定义了 Deployment、StatefulSet 和 Service 等资源。 这些资源代表软件应用程序的构建块。Kubernetes 集群中的各种控制器根据这些资源做出反应， 创建更多的 Kubernetes 资源或配置一些软件或硬件来实现我们的目标。

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

要控制集群中定义的资源允许哪些类型的设置，除了 RBAC 之外，还需要准入控制。 从 Kubernetes 1.3 开始，内置 PodSecurityPolicy 一直被作为 Pod 安全相关字段的准入控制机制。 使用 PodSecurityPolicy，可以防止“创建 Pod”这个能力自动变成“每个集群节点上的 root 用户”， 并且无需部署额外的外部准入控制器。

现在为什么 PodSecurityPolicy 要消失？

自从首次引入 PodSecurityPolicy 以来，我们已经意识到 PSP 存在一些严重的可用性问题， 只有做出断裂式的改变才能解决。

实践证明，PSP 应用于 Pod 的方式让几乎所有尝试使用它们的人都感到困惑。 很容易意外授予比预期更广泛的权限，并且难以查看某种特定情况下应用了哪些 PSP。 “更改 Pod 默认值”功能很方便，但仅支持某些 Pod 设置，而且无法明确知道它们何时会或不会应用于的 Pod。 如果没有“试运行”或审计模式，将 PSP 安全地改造并应用到现有集群是不切实际的，并且永远都不可能默认启用 PSP。

有关这些问题和其他 PSP 困难的更多信息，请查看 KubeCon NA 2019 的 SIG Auth 维护者频道会议记录：