🛡️ Kubernetes PSA安全级别，到底阻止了什么？（深度分析）

7 月 19, 2026

—

大家好！在上一篇文章中，我们探讨了 Pod Security Admission (PSA) 的概念和应用方法。今天，作为后续，我们将深入剖析 PSA 的核心——三种安全标准 (Pod Security Standards)，具体了解它们“阻止和允许哪些配置”。

应用 PSA 后，您的 Pod 是否经常陷入 Error 状态？或者您想应用 Restricted 级别，但不知道该如何修改？本文将为您提供完美的总结。🚀

1. 级别 0: Privileged (特权) 🔓

“一切都被允许的法外之地”

此策略被有意地完全开放。

限制： 无
允许： 主机内核访问、root 权限、主机网络使用等一切皆有可能。
适用对象： CNI 插件、存储驱动、节点管理代理等系统级 Pod。

⚠️ 注意

绝不能将此级别应用于一般的 Web 应用程序或微服务。一旦被黑客入侵，整个节点都将面临风险！

2. 级别 1: Baseline (基线) 🚧

“最低限度的安全保障，通用应用程序的标准”

这是一项基本的安全策略。它阻止通过权限提升 (Privilege Escalation) 对主机节点造成损害的行为。大多数通用容器镜像在此级别下无需修改即可良好运行。

🚫 主要限制 (被阻止的内容)

禁止特权容器 (privileged: true)

阻止容器直接访问主机设备。

禁止共享主机命名空间

hostNetwork: true: 无法共享主机的网络。
hostPID: true: 无法查看主机的进程 ID。
hostIPC: true: 无法访问主机上的进程间通信。

主机端口限制

限制占用主机的特定端口 (0-65535)。

限制添加特定 Linux 功能 (Capabilities)

阻止添加对系统具有致命影响的功能（例如：CAP_SYS_ADMIN, CAP_MKNOD 等）。

禁止危险的 Sysctls

修改内核参数的 sysctls 设置中，不安全的不能使用。

主机路径 (HostPath) 卷

注意： Baseline 并非完全禁止 HostPath 本身，但建议严格限制其使用（实际的阻止在 Restricted 级别执行）。

3. 级别 2: Restricted (受限) 🏰

“最高级别的安全，最佳实践”

此级别包含 Baseline 的所有限制，并增加了强大的规则，以进一步隔离 Pod 并最小化攻击面。您可能需要修改 Pod 规范 (YAML) 才能通过此级别。

🚫 额外限制 (Baseline + α)

此级别必须明确设置以下条件才能通过：

1. 禁止 Root (UID 0) 运行 👮

容器必须以非 Root 用户（非 UID 0）身份运行。
YAML 必需设置：

securityContext:
  runAsNonRoot: true
  runAsUser: 1000 # 非零数字

2. 禁止权限提升 (Privilege Escalation) 📉

阻止进程获取比其父进程更高的权限。这会阻止执行 setuid 二进制文件等操作。
YAML 必需设置：

containers:
  securityContext:
    allowPrivilegeEscalation: false

3. Linux 功能 (Capabilities) 初始化 🗑️

即使是容器运行时默认提供的功能也必须全部丢弃 (DROP ALL)。如果需要，仅 NET_BIND_SERVICE 等功能可以被明确允许。
YAML 必需设置：

containers:
  securityContext:
    capabilities:
      drop: ["ALL"]

4. 卷类型限制 💾

可以访问主机文件系统的 HostPath 卷绝对不能使用。
允许的卷： 仅允许 ConfigMap, Secret, EmptyDir, PersistentVolumeClaim, DownwardAPI, Projected 等 Kubernetes 抽象卷。

5. 应用 Seccomp 配置文件 🛡️

必须配置 Seccomp，这是一项系统调用过滤功能。
YAML 必需设置：

securityContext:
  seccompProfile:
    type: RuntimeDefault # 或 Localhost

🧐 一目了然的总结表

限制项	Privileged (特权)	Baseline (基线)	Restricted (受限)
特权容器	允许 ✅	阻止 🚫	阻止 🚫
主机网络/PID/IPC	允许 ✅	阻止 🚫	阻止 🚫
Linux 功能	无限制	禁止添加危险功能	必须全部丢弃 (DROP ALL)
Root 用户运行	允许 ✅	允许 ✅	禁止 (必须是非 Root)
权限提升 (Escalation)	允许 ✅	允许 ✅	禁止 (必须为 False)
卷类型	全部允许 (包括 HostPath)	全部允许	仅允许核心卷 (禁止 HostPath)

—

💡 通过 Restricted 级别的最佳实践 YAML

要在 Restricted 命名空间中部署，请参考以下模板。这正是安全最佳实践。

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  # [必需] Pod 级别安全上下文
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: my-app:1.0
    # [必需] 容器级别安全上下文
    securityContext:
      allowPrivilegeEscalation: false
      runAsUser: 1001  # 禁止 Root(0)
      capabilities:
        drop:
          - ALL # 删除所有权限

总结 📝

建议最初从 Baseline 开始，熟悉操作，然后逐步加强到 Restricted。特别是对于直接暴露在互联网上的 Web 应用程序，强烈建议应用 Restricted 级别。

安全并非不便，而是使我们的服务更加坚固的过程！下一篇文章中，我将带来 PSA 故障排除案例。👋