K8s Pod 安全策略 (PSP) 替代方案：Pod Security Admission

K8s Pod 安全策略 (PSP) 寿终正寝：Pod Security Admission 横空出世！🎉 (以及一点点怀旧…)

大家好！我是你们的老朋友，也是你们在 Kubernetes 这片云原生大陆上的探险向导。今天我们要聊一个 Kubernetes 圈子里的大新闻，一个既让人激动又让人略带伤感的消息：Pod Security Policy (PSP) 终于要退休了！取而代之的，是更加强大、更加灵活、也更加易用的 Pod Security Admission (PSA)。

想象一下，PSP 就像一位严厉的老管家，兢兢业业地守护着你的 Kubernetes 集群，确保每一个 Pod 都规规矩矩，不越雷池一步。然而，这位老管家规矩太多，配置复杂，有时候甚至会让你觉得束手束脚，难以施展。

而 PSA，就像一位更开明、更智慧的新管家，它仍然会守护你的集群安全，但它更加理解你的需求，更加灵活地执行安全策略，让你在保障安全的前提下，能够更加自由地驰骋在云原生世界！🚀

那么，为什么要告别 PSP？PSA 又有哪些过人之处呢？让我们一起深入探讨一下！

告别，是为了更好的相遇：为什么 PSP 需要退休？

PSP，全称 Pod Security Policy，在 Kubernetes 的早期版本中，扮演着至关重要的角色。它定义了一系列安全策略，例如是否允许 Pod 以 root 用户运行，是否允许使用 host network 等等。通过 PSP，我们可以有效地限制 Pod 的权限，从而提高集群的安全性。

然而，随着 Kubernetes 的不断发展，PSP 的一些缺点也逐渐暴露出来：

配置复杂，学习曲线陡峭： PSP 的配置非常繁琐，需要定义大量的 YAML 文件，而且需要深入了解 Kubernetes 的各种安全概念。对于新手来说，学习曲线非常陡峭。
灵活性不足： PSP 的配置是全局性的，这意味着一个 PSP 会影响到集群中的所有 Pod。这在某些情况下可能会导致灵活性不足，例如，我们可能需要对不同的命名空间应用不同的安全策略。
调试困难： 当 Pod 因为违反 PSP 而无法创建时，错误信息往往不够明确，导致调试困难。
废弃是必然： Kubernetes 官方已经宣布 PSP 将在未来的版本中被移除，这使得 PSP 成为一个技术债务。

总而言之，PSP 虽然在早期版本中发挥了重要作用，但它已经无法满足 Kubernetes 日益增长的安全需求。是时候告别这位老管家，迎接更加先进的 PSA 了！👋

PSA：新一代的安全守护者

Pod Security Admission (PSA) 是 Kubernetes 官方推荐的 PSP 替代方案。它是一个内置的准入控制器，能够根据预定义的 Pod 安全标准 (Pod Security Standards, PSS) 来验证 Pod 的安全配置。

PSA 最大的优势在于它极大地简化了安全策略的配置和管理。它将安全策略抽象成三个级别：

Privileged： 无限制的策略，允许 Pod 执行任何操作。这个级别主要用于系统级的 Pod，例如 Kubernetes 的核心组件。
Baseline： 最小化的策略，禁止 Pod 执行一些高风险的操作，例如使用 host network 或 host PID。这个级别适用于大多数应用程序。
Restricted： 最严格的策略，进一步限制 Pod 的权限，例如禁止使用 host volume 或 host path。这个级别适用于对安全性要求极高的应用程序。

这三个级别就像是金字塔一样，Privileged 位于顶端，权限最高，但风险也最大；Restricted 位于底端，权限最低，但安全性最高。你可以根据你的应用程序的需求，选择合适的安全级别。

PSA 的优势：

易于使用： PSA 的配置非常简单，只需要在命名空间上添加一个 label 即可。
灵活性强： PSA 可以针对不同的命名空间应用不同的安全级别。
可观测性好： PSA 能够提供详细的审计日志，方便我们了解 Pod 的安全状况。
无需额外组件： PSA 是 Kubernetes 的内置组件，无需安装额外的插件。

PSA 的工作原理：解密准入控制的魔法

PSA 的核心在于准入控制 (Admission Control)。准入控制是 Kubernetes 的一个重要特性，它允许我们在 Pod 被创建之前，对其进行验证和修改。

当一个 Pod 被创建时，准入控制器会拦截这个请求，并根据预定义的策略对其进行验证。如果 Pod 符合策略，准入控制器会允许其被创建；否则，准入控制器会拒绝这个请求，并返回一个错误信息。

PSA 就是一个准入控制器，它会根据 PSS 来验证 Pod 的安全配置。当一个 Pod 被创建时，PSA 会检查其安全配置是否符合预定义的 PSS 级别。如果 Pod 符合 PSS 级别，PSA 会允许其被创建；否则，PSA 会拒绝这个请求。

如何使用 PSA：手把手教你玩转新安全策略

现在，让我们一起来看看如何使用 PSA 来保护你的 Kubernetes 集群。

启用 PSA： PSA 是 Kubernetes 的内置组件，默认情况下是启用的。但是，为了确保 PSA 能够正常工作，你需要确保 PodSecurity 准入控制器被启用。你可以通过查看 API Server 的配置来确认这一点。
选择 PSS 级别： 根据你的应用程序的需求，选择合适的 PSS 级别。一般来说，对于大多数应用程序，Baseline 级别就足够了。对于安全性要求极高的应用程序，可以选择 Restricted 级别。
配置命名空间： 在命名空间上添加一个 label，指定其使用的 PSS 级别。例如，要将命名空间 my-namespace 的 PSS 级别设置为 Baseline，你可以执行以下命令：
```
kubectl label ns my-namespace pod-security.kubernetes.io/enforce=baseline
```
这个命令会在命名空间 my-namespace 上添加一个 label pod-security.kubernetes.io/enforce=baseline。这个 label 告诉 PSA，这个命名空间中的所有 Pod 都必须符合 Baseline 级别的 PSS。

你还可以使用 warn 和 audit 模式来配置 PSA。warn 模式会允许 Pod 被创建，但会发出一个警告信息。audit 模式会将所有违反 PSS 的 Pod 的信息记录到审计日志中。

例如：
```
kubectl label ns my-namespace pod-security.kubernetes.io/warn=baseline pod-security.kubernetes.io/audit=baseline
```
验证 Pod 安全配置： 创建一个 Pod，并观察其是否符合 PSS 级别。如果 Pod 不符合 PSS 级别，PSA 会拒绝这个请求，并返回一个错误信息。

例如，创建一个违反 Baseline 级别的 Pod：
```
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: privileged-container
    image: nginx
    securityContext:
      privileged: true
```
如果你在命名空间 my-namespace 中创建这个 Pod，PSA 会拒绝这个请求，并返回一个错误信息，告诉你这个 Pod 违反了 Baseline 级别的 PSS。

PSS 级别详解：深入了解安全策略的内涵

为了更好地理解 PSA 的工作原理，我们需要深入了解 PSS 的三个级别：Privileged、Baseline 和 Restricted。

特性	Privileged	Baseline	Restricted
特权容器	允许	禁止	禁止
hostPID	允许	禁止	禁止
hostNetwork	允许	禁止	禁止
hostPorts	允许	允许，但端口号必须大于 1024	禁止
hostPath volumes	允许	禁止使用 hostPath volumes	禁止使用 hostPath volumes
Capabilities	允许	默认capabilities (SYS_MODULE, SYS_RAWIO, SYS_PACCT, SYS_ADMIN, SYS_NICE, SYS_RESOURCE, SYS_TIME, SYS_CHOWN, SYS_PTRACE, SYS_NICE, KILL, SETFCAP, SETPCAP, NET_ADMIN, NET_BIND_SERVICE, NET_RAW, IPC_LOCK, IPC_OWNER, CHOWN, DAC_OVERRIDE, FOWNER, FSETID, KILL, SETGID, SETUID, SETFCAP, SETPCAP, NET_RAW, SYS_CHROOT) 需要显式删除才能使用	必须明确指定capabilities，并且不能添加 ALL capabilities。
AppArmor	允许	强制使用 AppArmor profile	强制使用 AppArmor profile
seccomp	允许	强制使用 `runtime/default` seccomp profile	强制使用 `seccomp.security.alpha.kubernetes.io/defaultProfileName: runtime/default` 或 `seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default` seccomp profile
卷类型	允许	允许使用 emptyDir, configMap, secret, persistentVolumeClaim, projected	允许使用 emptyDir, configMap, secret, projected, downwardAPI, persistentVolumeClaim (需要遵守 StorageClass 的限制)
特权容器	允许	禁止	禁止
runAsUser	允许	必须设置 `runAsUser` 或 `runAsGroup`，并且 `runAsUser` 必须是非 0 用户	必须设置 `runAsUser` 或 `runAsGroup`，并且 `runAsUser` 必须是非 0 用户，并且 `runAsNonRoot` 必须设置为 `true`
allowPrivilegeEscalation	允许	必须显式设置为 `false`	必须显式设置为 `false`
镜像来源	允许	允许	建议使用可信的镜像仓库，并使用镜像签名技术

通过这个表格，你可以清晰地了解每个 PSS 级别的具体限制。

从 PSP 到 PSA：平滑过渡的指南

如果你已经在使用 PSP，那么你需要将你的安全策略迁移到 PSA。这是一个逐步迁移的过程，可以分为以下几个步骤：

评估你的 PSP： 仔细评估你的 PSP，了解其具体限制。
选择合适的 PSS 级别： 根据你的 PSP 的限制，选择合适的 PSS 级别。
配置命名空间： 在命名空间上添加 label，指定其使用的 PSS 级别。
测试： 在测试环境中测试你的应用程序，确保其能够正常工作。
逐步迁移： 将你的应用程序逐步迁移到 PSA。
移除 PSP： 在确认所有应用程序都已成功迁移到 PSA 后，移除 PSP。

在迁移过程中，你可以使用 warn 和 audit 模式来配置 PSA，以便在不影响应用程序正常运行的情况下，了解 Pod 的安全状况。

PSA 的未来：更多可能性，更多期待

PSA 是 Kubernetes 安全领域的一个重要里程碑。它简化了安全策略的配置和管理，提高了集群的安全性，并为未来的安全发展奠定了基础。

未来，我们可以期待 PSA 能够提供更多的功能，例如：

自定义 PSS： 允许用户自定义 PSS 级别，以满足更特定的安全需求。
动态 PSS： 根据 Pod 的运行时状态，动态调整 PSS 级别。
与第三方安全工具集成： 与第三方安全工具集成，提供更全面的安全保护。

总结：拥抱 PSA，开启更安全的云原生之旅！

PSP 已经完成了它的历史使命，是时候告别这位老管家，拥抱更加先进的 PSA 了！PSA 简化了安全策略的配置和管理，提高了集群的安全性，并为未来的安全发展奠定了基础。

拥抱 PSA，让我们一起开启更安全的云原生之旅！🚀

希望今天的分享对你有所帮助！如果你有任何问题，欢迎在评论区留言。我们下期再见！👋