Linux Kubernetes Pod Security Admission (PSA) 的 enforce / audit / warn 模式

psa 的 enforce/audit/warn 分别拦截 pod 创建（403拒绝）、记录违规日志（放行）和返回warning头（黄色提示），三者独立不降级；仅通过命名空间 annotation 控制，格式为 pod-security.admission.control.k8s.io/{enforce,audit,warn}=level:version，restricted:v1 要求 runasnonroot、seccompprofile、allowprivilegeescalation 等多项硬性约束。

PSA 的 enforce / audit / warn 到底在拦什么？

PSA 不是“开关式”策略，而是三类独立生效的策略执行层：enforce 确实会拒绝 Pod 创建；audit 会在 API Server 日志里记下违规但放行；warn 是 kube-apiserver 返回 http 200 + 一个 Warning 头（客户端能看到，kubectl 会打印成黄色提示）。三者互不替代，也不会自动降级——比如开了 enforce 和 warn，违规 Pod 就直接被拒，根本不会走到 warn 那步。

• enforce 生效于 admission chain 的 MutatingAdmissionWebhook 之后、ValidatingAdmissionWebhook 之前，失败直接返回 403
• audit 和 warn 都依赖 PodSecurity 内置插件的日志/响应逻辑，不改变请求结果
• 同一命名空间不能混用不同级别：比如你给 ns A 设了 enforce: baseline:v1，就不能再加 audit: restricted:v1 —— PSA 只认一个 pod-security.admission.control.k8s.io/ annotation

怎么配才真正生效？看 annotation 写法和命名空间边界

PSA 策略只通过命名空间级别的 annotation 控制，没别的入口。常见错误是写错 key、value 格式，或误以为 cluster-wide 配置能覆盖 Namespace。

• 必须用标准 annotation key：pod-security.admission.control.k8s.io/enforce、pod-security.admission.control.k8s.io/audit、pod-security.admission.control.k8s.io/warn
• value 必须是 level:version 格式，比如 baseline:v1，不能写成 baseline 或 v1 单独出现
• annotation 只对所在命名空间新创建的 Pod 生效，已存在的 Pod 不受影响（哪怕重启也不会重检）
• 如果命名空间没设任何 PSA annotation，就完全不触发 PSA 检查——不是“默认宽松”，是“彻底绕过”

示例：

kubectl annotate ns myapp    pod-security.admission.control.k8s.io/enforce=restricted:v1    pod-security.admission.control.k8s.io/audit=baseline:v1    pod-security.admission.control.k8s.io/warn=restricted:v1

restricted:v1 拦住哪些东西？别只盯着 root 用户

很多人以为 restricted:v1 就是“禁止 root”，其实它是一组硬性组合规则，漏掉任意一条都会被 enforce 拒绝：

• runAsNonRoot 必须为 true（或容器指定了非 0 runAsUser）
• seccompProfile.type 必须是 RuntimeDefault 或 Localhost（不能是 Unconfined）
• allowPrivilegeEscalation 必须为 false
• capabilities.drop 至少包含 ALL（允许额外 add，但 drop 不能空）
• hostNetwork、hostPID、hostIPC 全部必须为 false
• volumes 类型受限：不允许 hostPath、emptyDir 的 medium: Memory 等高风险类型

注意：audit 和 warn 模式下，这些字段只是被记录或提示，但 Pod 仍能跑起来——所以线上先开 audit 观察一周，比直接上 enforce 更稳妥。

为什么 kubectl apply 后没报错，但 Pod 一直 Pending？

典型现象：你加了 enforce: restricted:v1，然后 kubectl apply -f pod.yaml 返回 success，但 kubectl get pod 显示 Pending，describe 里看不到明显拒绝信息。

这是因为 PSA 拒绝发生在 admission 阶段，API Server 直接返回 403，而 kubectl apply 默认不显示服务端 warning 或 Error body（尤其当 server 返回的是纯 json 错误时）。

• 真正要看拒绝原因，得加 --v=6：

  kubectl apply -f pod.yaml --v=6 2>&1 | grep -A5 "admission control"

• 或者直接用 curl 模拟 POST，看原始响应体里的 message 字段
• 常见隐形坑：Deployment 里没写 securityContext，但用了 Helm chart 自带的 serviceAccount，而该 SA 绑定了 privileged ClusterRole —— PSA 不管 RBAC，但它会拦下最终生成的 Pod spec，而这个 spec 可能因 controller 注入（如 istio sidecar）意外带上 hostNetwork: true

PSA 的 enforce 模式不报错、不提示、不妥协，它只做一件事：匹配失败就 403。所以验证策略前，务必用 kubectl auth can-i 辅助判断权限是否足够，但更要直接试跑最小 Pod YAML，别信文档里的“应该可以”。