Kubernetes Pod Security Standards 从 Baseline 到 Restricted 的分阶段落地：准入评估、违规清单处置与回滚

在现有 Kubernetes 集群中启用 Pod Security Standards（PSS），难点通常不是给命名空间加一组标签，而是确认哪些业务依赖当前权限、哪些控制器会在下一次扩缩容时创建不合规的 Pod，以及收紧策略后如何恢复。Pod Security Admission（PSA）可以先用审计和告警观察违规，再逐命名空间强制执行，但它不会自动修复现有 Pod，也不能保证所有业务依赖都已被覆盖。

本文面向具备集群管理权限的管理员和平台安全工程师，适用于能够使用 PSA 的集群。操作前应确认 API Server 已启用该准入控制器、审计日志可获取，并在测试环境验证所用 Kubernetes 版本的策略语义。生产变更需要业务负责人参与，尤其要覆盖有状态服务、定时任务和低频运维任务。

先分清策略等级、执行模式和版本边界

PSS 定义安全要求，PSA 是 Kubernetes 内置的准入实施机制。两者不是同一个概念。

PSA 的三个模式可以分别设置不同等级：

• audit：不因该模式下的违规而拒绝请求；违规信息以审计注解形式记录，前提是集群的审计配置保留了相关事件。
• warn：不因该模式下的违规而拒绝请求；向发起请求的客户端返回警告。
• enforce：拒绝不符合所选等级的新 Pod 准入请求。

这三个模式可独立设置。例如，enforce=baseline 与 audit=restricted、warn=restricted 可以并存：Baseline 负责当前拦截，Restricted 用于发现下一阶段的问题。如果 Baseline 尚未验证，不要把它当作无影响的起点；先保留现有强制等级，完成评估后再收紧。

PSA 自 Kubernetes v1.23 作为 Beta 功能引入，在 v1.25 进入稳定阶段；实际可用性还取决于集群版本和 API Server 配置。PSS 的具体检查随 Kubernetes 版本演进，尤其应核对操作系统相关字段及各版本允许的设置。命名空间可以通过 enforce-version、audit-version、warn-version 分别固定策略版本；latest 则会随 API Server 版本变化。升级集群时，应把策略版本更新作为独立变更验证。

准备：确定范围并保存现状

先选择一个业务依赖清晰、可恢复的测试命名空间。将下面的名称替换为实际值：

NS=app-staging

kubectl version
kubectl get namespace "$NS" --show-labels
kubectl get deployment,statefulset,daemonset,job,cronjob -n "$NS"
kubectl get pods -n "$NS" -o wide

同时确认：

1. 准入链与豁免：检查 PSA 是否启用、集群级默认策略是什么，以及命名空间、用户或 RuntimeClass 是否被配置为豁免。豁免请求会跳过 PSA 的 enforce、audit 和 warn 检查，不能用它证明工作负载合规。
2. 审计可见性：与集群审计日志负责人确认策略和日志采集范围，并用一个已知不合规的测试请求验证能否查到 PSA 违规注解。没有事件不等于没有违规。
3. 工作负载清单：记录控制器、副本数、镜像、服务账号、业务负责人、部署来源和恢复方式。还要纳入初始化容器、临时容器、CronJob、运维脚本以及可能扩缩容的工作负载。
4. 变更与恢复权限：确认执行人能修改命名空间标签，并能在 GitOps 或其他自动化系统中同步变更，避免手工回滚后又被自动覆盖。

保存命名空间和工作负载的当前配置，尤其记下六个 PSA 标签的原值或不存在状态：

kubectl get namespace "$NS" -o yaml > "${NS}-namespace-before.yaml"
kubectl get deployment,statefulset,daemonset,cronjob -n "$NS" -o yaml \
  > "${NS}-workloads-before.yaml"

这些文件是排查和恢复参考，不建议未经检查直接整体 apply：导出的对象可能包含不应回写的状态或元数据。

Restricted 违规清单：先区分缺省配置与真实权限需求

下表列出迁移中常见的检查点，具体规则以目标集群所固定的 PSS 版本为准。容器级设置需要覆盖普通容器和初始化容器等适用位置；不能只修改 Pod 级配置就假定全部容器合规。

以下是 linux 工作负载的示意片段，不是适用于所有镜像的通用补丁：

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: example/app:tag
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

10001 仅作示例：镜像必须允许该身份启动，并能访问所需文件、证书、临时目录和持久卷。修改 UID/GID 可能导致已有卷不可读写；应先在测试环境检查目录属主、挂载权限和应用行为。Windows Pod 及较早 Kubernetes 版本的检查存在差异，不应直接套用该 linux 片段。

对每条违规记录，至少保留命名空间、控制器、容器、字段、责任人、业务原因、修复方案和验证结果。真正需要节点权限或宿主机访问的组件，应单独评审并放到适当的隔离边界，而不是为了让普通业务通过而整体放宽生产命名空间。例外需要负责人、范围、到期时间和定期复核。

实施：按命名空间从审计走到强制

下面的例子将目标策略版本写为 v1.30，只用于展示固定版本的写法。操作前必须替换为集群支持且已验证的版本，并确认它与预期检查规则一致。

第一阶段：保留现有强制等级，启用 Restricted 审计

先不要修改现有 enforce 标签：

PSS_VERSION=v1.30

kubectl label namespace "$NS" \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version="$PSS_VERSION" \
  --overwrite

观察覆盖正常发布、扩缩容、定时任务和运维操作的完整业务周期。审计依赖请求发生：长时间不重建的旧 Pod、暂停的 CronJob 或未触发的故障恢复路径，可能不会自然出现在这一阶段的日志里。

因此，要把审计结果与控制器清单交叉核对，并在授权的测试环境中通过发布演练或服务端 dry-run 补充检查。服务端 dry-run 有助于发现准入警告，但不能代替真实 Pod 创建、调度、挂载和应用健康验证。

第二阶段：增加告警并整改模板

kubectl label namespace "$NS" \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version="$PSS_VERSION" \
  --overwrite

对部署清单运行服务端预检，并保留客户端输出：

kubectl apply --dry-run=server -n "$NS" -f ./workloads/

检查输出中的 Restricted 警告，结合审计日志形成违规清单。对于 Deployment 等控制器，应修改版本库或部署系统中的 Pod 模板，而不是只修改现有 Pod；否则下次重建仍会恢复旧配置。

整改后，在测试环境实际滚动更新并检查：

• 新 Pod 是否被准入、成功调度并达到 Ready；
• 初始化容器、健康探针、日志写入和持久卷访问是否正常；
• 应用读写、网络连接、定时任务和故障恢复是否符合预期；
• 已知违规是否消失，是否引入新的业务错误。

如果当前命名空间尚未强制 Baseline，可先用同样的方法评估 Baseline，再单独将 enforce 设为 baseline 并观察。不要因为 Restricted 审计已开启，就假定 Baseline 强制不会影响后续 Pod 创建。

第三阶段：小范围强制 Restricted

完成整改、业务验证和回滚演练后，对试点命名空间启用：

kubectl label namespace "$NS" \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version="$PSS_VERSION" \
  --overwrite

修改命名空间的强制标签时，API Server 可能针对现有 Pod 给出警告；应记录并处理这些信息。标签变更不会修改或驱逐已运行的 Pod，因此“当前业务未中断”不代表旧模板符合 Restricted。后续扩容、节点故障重建或发布时，旧模板仍可能创建失败。

建议按命名空间分批推进：每批确认审计覆盖、违规处置、业务负责人确认和回滚准备，再进入下一批。观察期应由业务周期和变更风险决定，而不是套用统一天数。

验证：区分准入拒绝与调度失败

先确认命名空间实际标签，以及控制器是否能够创建新 Pod：

kubectl get namespace "$NS" --show-labels
kubectl get pods -n "$NS" -o wide
kubectl get events -n "$NS" --sort-by=.lastTimestamp
kubectl describe deployment -n "$NS" <deployment-name>
kubectl rollout status deployment/<deployment-name> -n "$NS"

重点查看控制器事件中的 FailedCreate、Forbidden 和具体 PSS 违规字段。Deployment 对象本身可能已被接受，但控制器创建不合规 Pod 时被拒绝，导致副本无法补齐；这属于准入失败，不是调度器资源不足。若 Pod 已创建但处于 Pending，则还需检查节点资源、污点、亲和性及卷等其他原因，不能一律归因于 PSA。

在授权的隔离测试命名空间中，可分别验证一个合规 Pod 能被接受、一个明确不合规的 Pod 被拒绝。测试结束后清理对象，并确认测试请求没有命中 PSA 豁免。生产环境不要为制造拒绝结果而引入高权限测试负载。

回滚：恢复原强制策略并确认副本恢复

当新 Pod 因 Restricted 被拒绝，且业务无法等待整改时，先确认变更前的实际标签。若原策略明确为固定版本的 Baseline，可恢复为：

kubectl label namespace "$NS" \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version="$PSS_VERSION" \
  --overwrite

如果原来是 privileged，或者原来没有 enforce 标签，应按保存的实际状态恢复，而不是一律改成 Baseline。删除原本不存在的标签可使用：

kubectl label namespace "$NS" \
  pod-security.kubernetes.io/enforce- \
  pod-security.kubernetes.io/enforce-version-

删除标签后，生效的可能是集群级默认策略，不一定等于 privileged；必须提前确认默认值。通常可保留 audit=restricted 和 warn=restricted 继续收集问题，但也应按变更前状态和业务需要决定。

回滚后执行以下验证：

1. 检查命名空间标签以及 GitOps 等系统的期望状态，防止策略再次被覆盖。
2. 查看控制器事件和 rollout status，确认新的 Pod 创建请求已成功，副本恢复至预期。
3. 检查 Pod Ready、服务端点、业务探针和关键事务；仅看到标签恢复不等于业务恢复。
4. 记录被拒绝的工作负载、违规字段、影响时长和恢复结果，修复模板后重新安排试点。

回滚 PSA 标签只改变后续准入判断，不会自动撤销已部署的应用配置，也不保证其他准入控制器或平台策略允许该 Pod。若标签回滚后仍无法创建，应继续根据最新事件排查，而不是反复放宽策略。

复盘与持续维护

Restricted 落地的完成标准不应只是“所有命名空间都有标签”。更可靠的证据是：策略版本明确、例外可追踪、常见与低频工作负载均经过验证，且强制失败时能够恢复服务。

后续应把 PSS 检查纳入部署预检和镜像开发流程，定期复核例外、审计覆盖及命名空间标签漂移。集群升级前，在测试环境以新策略版本重新运行违规清单和业务验证；确认无误后，再分批更新固定版本，避免 Kubernetes 升级与安全策略收紧同时发生而难以定位问题。