6.3：Pod 安全标准

在 Kubernetes 安全治理里，Pod 是最值得重点盯住的对象。因为很多危险能力——比如特权容器、HostPath、hostNetwork、额外 capabilities、关闭 seccomp——最终都是落在 Pod 规格上的。Pod Security Standards（PSS）要解决的问题，就是给集群建立一套统一、清晰、可执行的 Pod 安全基线::cite[159]。

本章你将学会

• Pod Security Standards 的背景与目标
• Privileged、Baseline、Restricted 三个级别分别限制什么
• Pod Security Admission（PSA）如何启用与使用
• 在 Kubernetes v1.32 场景下，应该如何制定实际可落地的安全基线

1. Pod Security Standards 是什么

Pod Security Standards（PSS）定义了三档安全策略，用于覆盖从宽松到严格的 Pod 安全需求。它不是某一个插件，而是一套标准化的策略语言和分级方法，让团队可以用一致的术语讨论“这个命名空间到底允许多危险的 Pod”::cite[159]。

在 v1.32 文档中，PSS 明确给出了三档级别：

这三档策略是逐级累积的：Restricted 包含了 Baseline 的要求，而 Baseline 又比 Privileged 更严格::cite[159]。

2. PSS 的背景与目标

Pod 安全治理如果没有统一标准，平台通常会出现两种极端：

• 要么“全放开”，开发方便但风险巨大
• 要么“规则很多但缺少层级”，团队沟通和落地都很痛苦

PSS 的目标就是把 Pod 安全策略抽象成三档可理解、可沟通、可执行的等级，并配合内置的 Pod Security Admission 在 namespace 维度落实::cite[158]。

你可以把它理解为：

• PSS：定义“标准”
• PSA（Pod Security Admission）：负责“执行”

3. 三个级别怎么理解

3.1 Privileged：完全信任型

Privileged 基本可以理解为“不设防”，它允许 Pod 规避很多常见容器隔离机制。例如，Pod 可以使用主机网络、运行特权容器等。这类策略通常只适合平台底层、节点运维、CNI、存储插件等受信任的系统组件::cite[159]。

如果一个业务命名空间长期处于 privileged，通常意味着：

• 开发自由度高
• 平台安全边界极弱
• 一旦容器逃逸或镜像被攻陷，影响面会迅速扩大

3.2 Baseline：默认业务环境的第一道门槛

Baseline 的目标不是“最安全”，而是“先挡住最明显的坑”。在 v1.32 中，它会禁止或限制以下高风险能力：

• 共享主机命名空间（hostNetwork、hostPID、hostIPC）
• 特权容器（privileged: true）
• hostPath 卷
• 任意增加 Linux capabilities
• 显式把 seccomp 设为 Unconfined
• 使用 hostPort（内置 PSA 不支持白名单，只能建议全部禁用）::cite[159]

这意味着：Baseline 很适合作为大多数普通业务 namespace 的起点。

3.3 Restricted：面向高信任要求的强约束

Restricted 在 Baseline 之上继续加固。v1.32 文档中，几个最关键的限制包括：

• allowPrivilegeEscalation: false
• runAsNonRoot: true
• runAsUser 不能为 0
• seccomp 必须显式为 RuntimeDefault 或 Localhost
• 必须 drop: ["ALL"]，且只允许按需加回 NET_BIND_SERVICE
• 仅允许有限的卷类型，如 configMap、secret、projected、emptyDir、persistentVolumeClaim 等::cite[159]

这档策略更贴近“默认零信任业务容器”的思路。如果你的业务没有强依赖宿主机能力，Restricted 通常是长期更值得追求的目标。

4. Pod Security Admission 是怎么工作的

Pod Security Admission（PSA）是 Kubernetes 的内置准入控制器，用于执行 PSS。它在请求已经通过认证和授权之后工作，并在 Pod 创建阶段按 namespace 标签判断是否要拒绝、告警或仅记审计日志::cite[158]。

PSA 提供三个模式：

这三个模式可以独立配置，也可以针对同一个 namespace 同时启用不同级别。例如：

• enforce=baseline
• warn=restricted
• audit=restricted

这种组合非常适合渐进式收紧安全基线::cite[158]。

5. PSA 的配置方式：给命名空间打标签

PSA 的使用方式很简单：给 namespace 打上标准标签。

pod-security.kubernetes.io/<MODE>: <LEVEL>
pod-security.kubernetes.io/<MODE>-version: <VERSION>

其中：

• <MODE> 可以是 enforce、audit、warn
• <LEVEL> 可以是 privileged、baseline、restricted
• <VERSION> 可以写具体版本，例如 v1.32，也可以写 latest::cite[158]

6. 实操一：为普通业务命名空间启用 Baseline

6.1 完整 YAML

apiVersion: v1
kind: Namespace
metadata:
  name: app-baseline
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.32
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.32
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.32

6.2 应用配置

kubectl apply -f ns-baseline.yaml

这种配置的含义是：

• 至少达到 baseline，否则不让进
• 如果离 restricted 还有差距，先给出 warning 和 audit 记录

这是一种很适合生产落地的“先卡底线、再逐步收紧”的方式::cite[158]。

7. 实操二：观察一个会被 Baseline 拒绝的 Pod

下面这个 Pod 使用了 privileged: true 和 hostNetwork: true，会违反 Baseline：

apiVersion: v1
kind: Pod
metadata:
  name: bad-pod
  namespace: app-baseline
spec:
  hostNetwork: true
  containers:
    - name: bad
      image: nginx:1.27
      securityContext:
        privileged: true

执行：

kubectl apply -f bad-pod.yaml

你应该会看到类似“违反 PodSecurity baseline”之类的错误，因为这些能力正是 Baseline 明确禁止的内容::cite[159]。

8. 实操三：为高安全要求命名空间启用 Restricted

8.1 命名空间 YAML

apiVersion: v1
kind: Namespace
metadata:
  name: app-restricted
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.32
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.32
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.32

8.2 一个能通过 Restricted 的 Pod 示例

apiVersion: v1
kind: Pod
metadata:
  name: good-pod
  namespace: app-restricted
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: nginx:1.27
      ports:
        - containerPort: 8080
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsUser: 10001
        runAsNonRoot: true

这个 Pod 满足 Restricted 中最关键的几条要求：

• 非 root 运行
• 不允许提权
• 使用 RuntimeDefault seccomp
• 丢弃全部 capability::cite[159]

9. v1.32 场景下，最值得关注的 PSS 细节

9.1 Baseline 并不等于“已经很安全”

很多团队会把 baseline 误解成“默认安全”。其实它更多是阻止明显危险配置，而不是完成全面加固。比如它允许不少默认配置继续存在，因此更适合做第一阶段基线，而不是终局::cite[159]。

9.2 Restricted 才更接近现代业务容器的安全默认值

对于无须宿主机能力、只需要正常网络和存储的业务应用，restricted 实际上更接近你真正想要的安全目标。尤其是 runAsNonRoot、allowPrivilegeEscalation=false、seccompProfile=RuntimeDefault 这些项，应该逐步成为团队模板默认值::cite[159]。

9.3 记得做版本钉住

PSA 标签支持 -version。生产环境建议显式写成 v1.32，而不是 latest。原因很简单：安全基线不应随着控制面升级悄悄变化，尤其是在你还没完成全量回归前::cite[158]。

9.4 工作负载模板也会被提前检查

PSA 不只看直接创建的 Pod。对于 Deployment、Job 这类带 Pod Template 的工作负载，audit 和 warn 也会作用到这些资源上，从而让你在真正创建 Pod 前就尽早发现问题；但 enforce 最终还是作用在实际 Pod 创建阶段::cite[158]。

10. v1.32 安全基线建议

下面是一套很实用的分层建议：

如果让我给出一个简洁建议，那就是：

• 老环境：先 baseline，再用 warn/audit 推 restricted
• 新环境：直接 restricted

11. PSA 豁免该怎么用

PSA 允许针对用户名、RuntimeClass、命名空间做显式豁免，但官方特别提醒：不要轻易豁免控制器 ServiceAccount，否则可能让任何能创建对应工作负载的用户间接绕过策略::cite[158]。

也就是说，豁免的正确思路不是“谁报错就给谁开口子”，而是：

1. 明确为什么需要例外
2. 例外限定在哪个 namespace / RuntimeClass / 组件
3. 保证例外是最小范围、可审计、可回收的

12. 常见落地误区

12.1 误区一：直接全局 privileged

这通常会让 PSS 形同虚设。即便你后面配了很多安全工具，只要 Pod 规格层面完全放开，攻击面依然很大。

12.2 误区二：把 Restricted 当成“开发不友好”所以永远不上

很多业务其实完全可以运行在 Restricted 下，只是团队模板、镜像用户、启动脚本没有提前规范。真正的问题往往不是 Restricted 太严，而是工程默认值太松。

12.3 误区三：只启用 warn，不启用 enforce

只 warn 不 enforce 的结果通常是“大家都看到 warning，但没人改”。如果一个基线你真的认同，就应该在合适时机切换到 enforce。

13. 本章小结

PSS 和 PSA 的组合，是 Kubernetes v1.32 中最值得优先落地的内置 Pod 安全能力之一。你需要记住：

• PSS 把 Pod 安全分成 privileged、baseline、restricted 三档::cite[159]
• PSA 通过 namespace 标签在创建阶段执行这些策略::cite[158]
• baseline 适合建立最低防线，restricted 更接近现代安全默认值::cite[159]
• 在生产环境里，建议显式钉住 v1.32 版本标签，避免策略随版本漂移::cite[158]
• 真正有效的落地方式，不是“一口气全局最严”，而是分命名空间、分阶段、可观测地推进

理解了 PSS，你就具备了“从 Pod 规格层面定义允许什么、不允许什么”的能力。下一章我们继续看 Secret 管理，解决“即便 Pod 安全了，敏感信息该怎么安全保存和轮换”的问题。

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！