4、Pod安全准入（PSA）进阶：Pod Security Admission介绍、命名空间标签策略、从PSP迁移到PSA的参数调优
4.1 Pod Security Admission（PSA）概述
Pod Security Admission（PSA）是 Kubernetes v1.23 引入的 内置准入控制器，用于替代已废弃的 PodSecurityPolicy（PSP）。PSA 通过 命名空间标签 定义安全策略，在 Pod 创建时自动执行安全校验，无需额外部署 Webhook 或 Operator。
核心优势： PSA 是 Kubernetes 原生组件，零外部依赖；策略定义简单（仅需标签）；支持 警告（warn）、审计（audit）、拒绝（enforce） 三种模式，可渐进式落地。
4.2 命名空间标签策略：三种安全等级
PSA 定义了三种预置安全等级，通过命名空间标签 pod-security.kubernetes.io/ 进行配置：
| 等级 | 标签值 | 适用场景 | 典型限制 |
|---|---|---|---|
| Privileged | privileged |
系统组件、监控、网络插件 | 无限制，允许所有特权操作 |
| Baseline | baseline |
通用工作负载 | 禁止特权容器、hostPID、hostNetwork、hostPath 等 |
| Restricted | restricted |
高安全敏感应用 | Baseline + 禁止非 root 用户、禁止 seccomp 未配置、限制 capabilities |
命名空间标签格式：
# 强制模式（拒绝违规 Pod）
pod-security.kubernetes.io/enforce: restricted
# 警告模式（仅输出警告，不拒绝）
pod-security.kubernetes.io/warn: baseline
# 审计模式（记录审计日志，不拒绝）
pod-security.kubernetes.io/audit: privileged
# 指定版本（可选）
pod-security.kubernetes.io/enforce-version: v1.28
最佳实践： 生产环境建议先使用
warn 和 audit 模式运行 1-2 个迭代周期，确认无违规后再切换为 enforce 模式，避免影响现有工作负载。
4.3 PSA 工作流程与决策逻辑
下图展示了 PSA 在 Pod 创建时的完整校验流程：
4.4 从 PSP 迁移到 PSA 的参数调优
PSP 到 PSA 的迁移不是简单的标签替换，需要针对 安全上下文 和 Pod 规范 进行参数调优。以下是关键迁移对照表：
| PSP 字段 | PSA 对应等级 | 调优参数 | 说明 |
|---|---|---|---|
privileged: true |
Privileged | 无限制 | PSA 中 Privileged 等级完全放行 |
hostPID / hostNetwork |
Baseline | securityContext.hostPID: false |
Baseline 禁止 host 共享 |
runAsUser: MustRunAsNonRoot |
Restricted | securityContext.runAsNonRoot: true |
Restricted 强制非 root |
seccomp: RuntimeDefault |
Restricted | securityContext.seccompProfile.type: RuntimeDefault |
Restricted 要求 seccomp 配置 |
allowedCapabilities |
Baseline / Restricted | Baseline 仅允许 NET_BIND_SERVICE |
Restricted 禁止所有 ADD 能力 |
4.5 迁移步骤与参数调优策略
- 审计现有 PSP 策略： 导出所有 PSP 对象，统计每个命名空间使用的 PSP 规则。
- 设置 PSA 审计模式： 为每个命名空间添加
pod-security.kubernetes.io/audit: baseline标签，收集违规 Pod 列表。 - 分析审计日志： 通过
kubectl get events -n <ns>或审计后端查看 PSA 审计记录，识别需要调整的 Pod。 - 调整 Pod 安全上下文： 对违规 Pod 添加
securityContext字段，满足 Baseline 或 Restricted 要求。 - 切换为警告模式： 将标签改为
warn，验证调整后的 Pod 是否仅产生警告而非错误。 - 最终启用强制模式： 确认无违规后，切换为
enforce标签，并删除旧 PSP 对象。
迁移避坑： 部分旧版 Helm Chart 或 Operator 可能未设置
securityContext，直接启用 enforce: restricted 会导致大量 Pod 创建失败。建议从 baseline 等级开始，逐步收紧。
4.6 PSA 与 PSP 架构对比
下图展示了 PSA 与 PSP 在集群中的架构差异：
4.7 参数调优实战：从 PSP 到 PSA 的配置示例
以下是一个典型的 PSP 规则及其对应的 PSA 标签配置：
# 旧 PSP 配置（已废弃）
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false
hostPID: false
hostNetwork: false
runAsUser:
rule: MustRunAsNonRoot
seccomp:
profiles:
- runtime/default
allowedCapabilities:
- NET_BIND_SERVICE
# 新 PSA 配置（命名空间标签）
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.28
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/warn: baseline
调优建议： 对于需要
NET_BIND_SERVICE 能力的应用（如监听低端口），PSA 的 Restricted 等级默认禁止所有 ADD 能力。此时应使用 baseline 等级，或在 Pod 的 securityContext.capabilities.drop 中显式声明。
4.8 迁移验证清单
| 检查项 | 验证方法 | 预期结果 |
|---|---|---|
| 命名空间标签生效 | kubectl get ns <ns> -o yaml |
标签存在且值正确 |
| 审计日志无违规 | kubectl get events -n <ns> --field-selector reason=PodSecurity |
无 audit 级别违规事件 |
| 警告模式无输出 | 创建测试 Pod 并观察 kubectl apply 输出 |
无 Warning 信息 |
| 强制模式拒绝违规 | 创建特权 Pod：kubectl run test --image=nginx --privileged |
被 deny 并返回错误 |
| 旧 PSP 对象已删除 | kubectl get psp |
无 PSP 对象返回 |
重要提醒： 删除 PSP 前必须确保所有命名空间已配置 PSA 标签，否则未受保护的命名空间将没有任何安全准入限制。建议先使用
audit 模式运行至少 72 小时，确认无遗漏后再执行 PSP 清理。