在K8S中，PodSecurityPolicy机制有何作用?

Kubernetes安全策略实战：从PodSecurityPolicy到Pod Security Admission

在Kubernetes集群中，Pod的安全性直接关系到整个系统的稳定性和抗攻击能力。PodSecurityPolicy（PSP） 曾是实现Pod安全管控的核心机制，但随着Kubernetes 1.21版本后其被标记为弃用（1.25版本正式移除），生产环境亟需向新一代方案迁移。本文将结合生产经验，解析PSP的作用、局限性及替代方案。

---

一、PodSecurityPolicy的核心作用（历史视角）

PSP的核心目标：通过预定义的安全策略，限制Pod的运行时权限，防止恶意或错误配置导致的安全风险。以下是其核心能力：

1. 权限最小化控制

• 禁止特权容器：防止容器以privileged: true运行（高危操作！）

  apiVersion: policy/v1beta1
  kind: PodSecurityPolicy
  spec:
    privileged: false  # 禁止特权模式
  

• 限制用户权限：强制容器以非root用户运行

  runAsUser:
    rule: MustRunAsNonRoot  # 必须非root
  

2. 资源访问隔离

• 文件系统保护：禁止挂载宿主机敏感目录

  allowedHostPaths:
  - pathPrefix: "/var/log"
    readOnly: true  # 仅允许只读挂载/var/log
  

• 网络隔离：限制使用宿主机网络命名空间

  hostNetwork: false  # 禁止使用主机网络
  hostIPC: false      # 禁止共享IPC
  hostPID: false      # 禁止共享PID
  

3. 能力（Capabilities）管控

• 裁剪Linux内核权限：仅允许必要的能力（如NET_BIND_SERVICE）

  allowedCapabilities: ["NET_BIND_SERVICE"]
  defaultAddCapabilities: []
  requiredDropCapabilities: ["ALL"]  # 默认禁用所有能力
  

---

二、生产环境中的PSP实战案例

场景1：防御容器逃逸攻击

• 问题：某业务Pod被恶意利用，通过挂载/路径获取宿主机权限
• PSP解决方案：

  allowedHostPaths:
  - pathPrefix: "/tmp"  # 仅允许挂载/tmp
    readOnly: true
  volumes:
  - configMap
  - secret             # 禁止hostPath类型卷
  

场景2：合规性要求

• 需求：金融业务强制所有容器以非root运行
• PSP配置：

  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    ranges:
    - min: 1000
      max: 65535
  

---

三、PSP的局限性及替代方案

为何PSP被弃用？

1. 复杂性高：需结合RBAC配置，策略冲突难排查
2. 默认拒绝陷阱：未明确授权的Pod会被拒绝，易导致服务中断
3. 缺乏层级控制：无法按Namespace差异化配置

替代方案：Pod Security Admission（PSA）

Kubernetes 1.22+ 内置的准入控制器，提供三类策略级别：

• Privileged：无限制（仅用于系统组件）
• Baseline：最低安全要求（推荐默认启用）
• Restricted：严格限制（适合高安全场景）

PSA配置示例：

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted  # 强制执行Restricted策略
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

---

四、迁移指南：从PSP到PSA

步骤1：评估现有PSP策略

# 列出所有PSP及其绑定关系
kubectl get psp
kubectl get clusterrolebindings -l kubernetes.io/psp=true

步骤2：映射PSP规则到PSA策略

PSP规则	PSA等效配置
privileged: false	启用Baseline/Restricted级别
runAsNonRoot: true	Restricted级别自动包含此规则
allowedCapabilities: []	Restricted级别禁用所有能力

步骤3：分阶段迁移

1. 监控模式：在Namespace添加audit和warn标签，观察日志
2. 逐步切换：优先在非生产环境启用enforce
3. 异常处理：对特殊Pod添加豁免注解

   metadata:
     annotations:
       pod-security.kubernetes.io/enforce-version: v1.28
       pod-security.kubernetes.io/exempt: user="admin",runtimeClass="privileged"
   

---

五、生产环境避坑指南

1. 灰度发布策略

   • 使用kubectl label ns staging pod-security.kubernetes.io/enforce=baseline
   • 通过Argo Rollouts逐步验证Pod兼容性

2. 关键检查项

   • 确保Init容器也符合安全策略
   • 验证CSI驱动、CNI插件等系统组件的豁免配置

3. 监控与审计

   # 查看PSA拦截事件
   kubectl get events --field-selector reason=FailedCreate
   # 审计日志分析
   kube-apiserver --audit-policy-file=policy.yaml
   

---

六、企业级安全架构建议

安全层级	工具链	场景
L1	PSA + NetworkPolicy	基础隔离
L2	Kyverno/OPA策略引擎	自定义合规规则
L3	Falco实时监控 + 审计日志	入侵检测
L4	硬件加密（SGX/TPM）	金融级数据保护

---

结语

虽然PSP已退出历史舞台，但其设计理念仍在PSA中延续。建议生产环境尽快迁移至PSA，并结合策略引擎（如Kyverno）实现更灵活的管控。安全策略的终极目标不是限制，而是为业务提供“安全的自由”——在保障底线的前提下，最大化创新效率。