Pod Security Admission 的三个执行等级

Pod Security Admission 是 Kubernetes 内置的准入控制器，它把 Pod 安全要求收敛为三个执行等级：privileged、baseline 和 restricted。三个等级不是并列的可选项，而是层层收紧的约束集，理解每一级覆盖什么、放行什么，才能决定工作负载应该落在哪一级，以及哪些风险需要靠等级之外的策略补足。

privileged 是默认的放开状态，不施加任何 Pod 安全限制。它适合系统组件、网络插件、存储驱动这类确实需要特权能力的工作负载。baseline 是第一个真正施加约束的等级，它禁止明显的特权行为，例如不允许 privileged 容器、不允许 hostPID 和 hostIPC、不允许 hostPath 卷、不允许添加 hostPort，同时要求默认的 seccomp 配置。这一级的定位是拦住那些几乎任何业务应用都不该有的能力，同时不要求应用做太多改造。restricted 则在 baseline 之上进一步收紧，它要求 Pod 以非 root 身份运行、禁止提权、丢弃全部 linux capabilities 后再按需显式添加、限制卷类型，并强制使用 RuntimeDefault 或更严格的 seccomp 配置。restricted 的目标是让工作负载按最小权限原则运行，但代价是应用本身必须支持非 root 和只读根文件系统。

实际使用中容易产生的误解是，restricted 就等于安全。它确实覆盖了身份、提权、能力和 seccomp 这些核心维度，但并非所有安全字段都在其检查范围内。典型的例子是 readOnlyRootFilesystem，这个字段不在 Pod Security Standards 的 restricted 必填清单里。也就是说，一个通过 restricted 准入的 Pod，其容器根文件系统仍然可能是可写的。这类缺口需要依赖 Kyverno、Gatekeeper 或 CI 检查来补足，而不是指望 PSA 一揽子解决。

选择执行等级时，应该先按工作负载的真实需求做分类，而不是一刀切上 restricted。需要特权能力的系统组件留在 privileged，普通业务应用先评估 baseline 能否满足，再尝试向 restricted 收敛。收敛前要逐项核对 restricted 的字段要求：镜像是否以非 root 用户启动、进程是否会提权、是否依赖被默认丢弃的能力、是否使用受限卷类型。任何一项不满足，都需要先改造再切换等级，而不是直接关掉准入。

等级切换本身也要讲究顺序。直接在命名空间上启用 enforce=restricted，可能瞬间阻断现有工作负载的创建和更新。更稳妥的做法是先以 audit 和 warn 模式观察一段时间，通过准入日志和告警确认影响面，再切换到 enforce。对于确实需要例外的负载，应通过策略引擎的例外机制或独立命名空间处理，并记录负责人和到期时间，而不是长期降低整个命名空间的强制等级。

Pod Security Admission 的价值在于提供了一条内置的、无需额外组件的基线防线。它不能替代完整的容器安全策略，但能把最常见的高风险配置挡在集群之外。理解三个等级各自管什么、不管什么，是正确使用这套机制的前提。