Kubernetes(k8s)中如何通过PodSecurityPolicy限制容器的运行时权限？

在k8s里用PodSecurityPolicy（PSP）限制容器权限，说白了就是给容器套个“紧箍咒”。比如，你先创建一个PSP策略，里面规定：不让容器用特权模式（privileged: false）、必须用非root用户跑（runAsUser范围限制）、禁止挂载宿主机敏感目录（比如/或/proc）。然后把这个策略通过RBAC绑定给具体的ServiceAccount，这样用这个账号创建的Pod就会被自动限制权限。举个栗子，你甚至可以禁止容器加内核参数或者限制文件系统只读。不过注意PSP现在已经被逐步弃用，新版本建议用Pod Security Admission来代替。

1. 启用PodSecurityPolicy准入控制器：在API Server配置中添加--enable-admission-plugins=PodSecurityPolicy并重启控制平面组件。
2. 创建PSP策略：定义yaml文件限制privileged特权模式、hostPID/hostIPC共享、volumes类型、root运行等安全参数。
3. 绑定RBAC权限：创建ClusterRole绑定ServiceAccount或User，确保特定命名空间下的Pod创建请求必须符合对应PSP策略。
4. 验证策略：通过创建测试Pod验证特权容器创建会被拒绝，符合基线配置的Pod可正常调度。

从技术管理角度，通过PodSecurityPolicy（PSP）限制容器运行时权限需分步实施：

1. 策略定义：明确禁止特权容器（privileged: false）、限制Linux Capabilities（如DROP ALL，仅允许必要能力）、强制非root用户运行（runAsNonRoot: true）、限制文件系统只读（readOnlyRootFilesystem: true）等核心规则。
2. 分级管控：根据业务场景划分PSP等级（如privileged/restricted），通过RBAC绑定不同ServiceAccount，避免一刀切影响业务灵活性。
3. 迁移风险：需注意PSP在K8s 1.25+已废弃，建议同时规划Pod Security Admission或OPA Gatekeeper的过渡方案。
4. 审计闭环：结合准入控制日志定期分析策略拦截事件，持续优化白名单机制。关键点在于平衡安全性与业务适配，建议通过Canary Deployment逐步收紧策略，避免因权限限制导致生产事故。

通过PodSecurityPolicy可限制容器运行时权限，如配置必须的非特权运行、禁止特权提升、限制root用户等规则，从而控制容器的安全上下文与权限范围。

在Kubernetes中通过PodSecurityPolicy（PSP）限制容器运行时权限的核心实践包括以下步骤与经验：

1. 权限控制：

   • 禁止特权模式：设置privileged: false，避免容器获得宿主机内核权限。
   • 限制Linux Capabilities：通过allowedCapabilities和requiredDropCapabilities删除高危能力（如SYS_ADMIN、NET_RAW），仅保留业务必要能力。
   • 关闭权限提升：设置allowPrivilegeEscalation: false，防止子进程获得更高权限。

2. 文件系统保护：

   • 强制只读根文件系统：readOnlyRootFilesystem: true，结合EmptyDir挂载写入路径。
   • 限制敏感挂载：通过allowedHostPaths屏蔽/proc、/dev等目录，避免容器逃逸。

3. 用户与组策略：

   • 禁止root用户：设置runAsUser: rule: MustRunAsNonRoot，强制容器以非root启动。
   • 限制用户组范围：通过supplementalGroups和fsGroup定义允许的GID范围。

4. 运行时隔离：

   • 限制宿主机命名空间共享：禁用hostPID、hostIPC、hostNetwork，避免跨容器进程可见性。
   • 控制卷类型：通过volumes字段仅允许业务必要的存储类型（如configMap、secret）。

实践中遇到的挑战：

• 兼容性问题：部分遗留应用依赖特权模式或特定Capability（如Java应用需NET_ADMIN），需通过风险评估后动态调整策略，或推动应用改造。
• 策略继承冲突：Init Container需临时高权限时，通过runtimeClassName隔离或拆分PSP策略，确保主容器仍受限制。
• 策略碎片化：多团队共用集群时，易出现PSP规则重复或冲突，需通过命名规范与自动化工具（如OPA）统一管理。
• 废弃替代风险：PSP在K8s 1.21后逐步废弃，需提前规划迁移至Pod Security Admission或Gatekeeper，采用enforce、audit、warn分级控制。

关键经验：

• 灰度生效：通过RBAC逐步绑定PSP到Namespace，监控拒绝事件，避免全局策略导致服务中断。
• 审计追踪：结合Falco或kube-audit日志监控异常Pod创建行为，并定期扫描集群中违反PSP的残留资源。
• 文档同步：将PSP约束纳入CI/CD准入检查，确保开发人员明确容器化要求，减少部署阶段摩擦。