Pod 安全标准版本固定的取舍

Pod 安全标准（Pod Security Standards）在 Pod Security Admission 中通过版本标签固定，例如 pod-security.kubernetes.io/enforce-version。这个设计看起来只是填一个字符串，实际却是一项需要长期维护的决策：固定版本意味着准入行为可预期，同时意味着集群不会自动获得新版本中更严格的规则。集群升级期间，这个取舍会被放大——控制面版本在变，节点版本在变，而命名空间上固定的策略版本不会跟着变。

固定版本的价值首先在于稳定性。PSA 的策略解释依赖所引用的标准版本，如果不显式固定，集群可能随控制面升级而采用不同的默认解释，原本通过的 Pod 突然被拒，或原本被限制的字段被放行。对多 API 服务器实例并存的集群，这种漂移尤其危险：不同实例若加载了不同版本的标准，同一份清单可能得到不一致的准入结果。固定版本把这类不确定性收敛为可比较的基线，使升级前后的准入决策具备对照条件。

代价同样明确。固定版本等于主动放弃新版本引入的收紧规则，安全边界停留在声明的那一刻。随着工作负载演进，旧版本标准可能不再覆盖新的风险面，而集群表面上仍显示策略已启用。这种“策略对象存在、保护未同步”的状态，比完全没有策略更难察觉。因此固定版本不是一次性配置，而应被视为带有到期评估义务的技术债：每次控制面升级、每次标准版本迭代，都应重新判断是否值得迁移。

在混合版本窗口内，取舍的判断依据应落在验证上，而非文档推断。准入控制在 API 服务器侧执行，节点版本差异不影响准入决策本身，但会影响被接受 Pod 的实际运行效果。可行的做法是：在隔离命名空间中准备预期允许与预期拒绝两类最小清单，用服务端试运行分别核对各 API 服务器实例的决策，并区分 PSA 拒绝与其他准入 Webhook 的拒绝。同时记录请求身份、命名空间标签与审计事件，确保一次成功不能代表所有实例一致。

更关键的一步是跨过准入去看节点。相同清单在不同节点上运行时，seccomp、权限提升、capabilities、用户身份等最终属性可能因运行时默认值和 kubelet 传递配置而不同。测试应覆盖显式声明安全上下文的清单，也覆盖有意依赖节点默认值的受控样例，并在容器内核对进程身份与可见能力集，用功能性负例确认旧节点与新节点结果一致。若发现默认值分歧，优先在工作负载中显式声明所需属性，再通过受控变更统一节点配置。

落到操作层面，固定版本的决策可以归纳为几条判断标准：命名空间是否承载安全敏感工作负载，决定固定版本的必要性；标准的版本跨度是否引入与现有工作负载冲突的规则，决定迁移成本；集群是否存在多 API 服务器或长期版本偏移，决定不固定所带来的不一致风险。每次升级把这三项重新过一遍，并把结论写入变更记录，固定版本才不至于变成无人复核的默认值。