podsecuritypolicy（psp）虽在v1.25+移除，但v1.19–v1.24集群仍广泛使用；启用需配置kube-apiserver的--enable-admission-plugins=podsecuritypolicy，再定义非特权基线策略、通过rbac绑定serviceaccount授权，并分阶段验证落地。
PodSecurityPolicy（PSP）虽已在 Kubernetes v1.25+ 正式移除，但大量生产集群（尤其是 v1.19–v1.24 版本）仍在使用。配置 PSP 的核心不是“加功能”，而是通过准入控制，在 Pod 创建前强制执行最小权限原则——禁止特权、限制用户、隔离主机资源、裁剪内核能力。
启用 PSP 准入控制器
这是前提，否则所有 PSP 资源都不生效：
- 编辑 kube-apiserver 启动参数，加入 --enable-admission-plugins=PodSecurityPolicy
- 常见位置：
/etc/kubernetes/manifests/kube-apiserver.yaml（静态 Pod 配置）或 systemd service 文件 - 重启 kube-apiserver 后，所有 Pod 创建将被拒绝，直到至少一个 PSP 和对应 RBAC 授权就绪
定义基础安全策略
避免“全开”或“全关”，从非特权基线起步。例如禁止 root、禁用特权、限制卷类型：
- privileged: false —— 禁止容器获得宿主机全部设备和能力
- runAsUser: rule: MustRunAsNonRoot —— 强制容器必须指定非 root 用户 ID
- readOnlyRootFilesystem: true —— 根文件系统默认只读，防止运行时篡改
-
volumes: ["configMap", "emptyDir", "persistentVolumeClaim"] —— 显式允许安全卷类型，排除
hostPath、secret（需单独授权）等高风险类型 - allowedCapabilities: [] 和 requiredDropCapabilities: ["ALL"] —— 移除所有默认能力，按需显式添加
绑定策略到服务账户（RBAC 授权）
PSP 不自动生效，必须通过 RBAC 明确授予使用权限：
- 创建 ClusterRole，verbs 设置为 use，resources 为
podsecuritypolicies - 用 ClusterRoleBinding 将该角色绑定到目标 ServiceAccount（如命名空间中的
defaultSA），或绑定到system:serviceaccounts:<namespace></namespace>组 - 关键点：kube-system 命名空间的组件（如 CoreDNS、metrics-server）也需被授权，否则集群可能异常
验证与渐进落地
上线前务必测试，避免“一刀切”导致业务中断：
- 先用
kubectl auth can-i use psp/<name> --as=system:serviceaccount:<ns>:<sa></sa></ns></name>检查授权是否生效 - 部署测试 Pod，观察事件：
kubectl describe pod <name></name>中若出现Forbidden: unable to validate against any pod security policy，说明策略未覆盖或授权缺失 - 建议分阶段：先为测试命名空间启用宽松策略（如仅禁用 privileged），再逐步收紧；生产环境应配合 PodSecurityContext 显式声明安全上下文，而非依赖 PSP 默认值
