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" # 仅允许挂载/tmpreadOnly: true volumes: - configMap - secret # 禁止hostPath类型卷
场景2：合规性要求
- 需求：金融业务强制所有容器以非root运行
- PSP配置：
runAsUser:rule: MustRunAsNonRoot seLinux:rule: RunAsAny supplementalGroups:ranges:- min: 1000max: 65535
三、PSP的局限性及替代方案
为何PSP被弃用？
- 复杂性高：需结合RBAC配置，策略冲突难排查
- 默认拒绝陷阱：未明确授权的Pod会被拒绝，易导致服务中断
- 缺乏层级控制：无法按Namespace差异化配置
替代方案：Pod Security Admission（PSA）
Kubernetes 1.22+ 内置的准入控制器，提供三类策略级别：
- Privileged：无限制（仅用于系统组件）
- Baseline：最低安全要求（推荐默认启用）
- Restricted：严格限制（适合高安全场景）
PSA配置示例：
apiVersion: v1
kind: Namespace
metadata:name: prodlabels:pod-security.kubernetes.io/enforce: restricted # 强制执行Restricted策略pod-security.kubernetes.io/audit: restrictedpod-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：分阶段迁移
- 监控模式：在Namespace添加
audit和warn标签，观察日志 - 逐步切换：优先在非生产环境启用
enforce - 异常处理：对特殊Pod添加豁免注解
metadata:annotations:pod-security.kubernetes.io/enforce-version: v1.28pod-security.kubernetes.io/exempt: user="admin",runtimeClass="privileged"
五、生产环境避坑指南
灰度发布策略
- 使用
kubectl label ns staging pod-security.kubernetes.io/enforce=baseline - 通过Argo Rollouts逐步验证Pod兼容性
关键检查项
- 确保Init容器也符合安全策略
- 验证CSI驱动、CNI插件等系统组件的豁免配置
监控与审计
# 查看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）实现更灵活的管控。安全策略的终极目标不是限制，而是为业务提供“安全的自由”——在保障底线的前提下，最大化创新效率。