Pod安全策略的核心配置与避坑指南
先问你个问题：你配置Pod时会特意指定securityContext吗？我猜很多人要么直接用默认配置，要么复制粘贴网上的模板。其实这里面藏着大学问，我去年帮一个游戏公司排查挖矿病毒时，发现病毒就是通过一个未限制用户权限的Pod跑起来的——那个Pod的runAsUser没设置，默认用root用户，直接把宿主机的文件系统给挂载进来了。
必改的3个核心配置项
先说最容易出问题的三个配置，你现在打开自己的Pod YAML文件对照着看，保准能发现问题：
第一个是特权容器开关（privileged）
。这个就像给Pod配了把”万能钥匙”，能直接访问宿主机的内核资源。我见过最夸张的案例是某金融公司的测试环境，为了图方便把所有Pod都设成privileged: true，结果一个开发误操作把宿主机的iptables规则清空了，整个集群断网半小时。记住：除了像监控Agent这种必须访问内核的组件，99%的业务Pod都该设成privileged: false，别给攻击者留机会。
第二个是用户权限控制。你肯定知道容器里不该用root用户跑服务，但实际配置时总有人偷懒。我 你在securityContext里明确设置runAsNonRoot: true，再指定一个非root用户ID，比如runAsUser: 1000。这里有个小技巧：可以在Dockerfile里就创建普通用户，然后在Pod配置里对应上，比如我习惯用uid=1000(gopher) gid=1000(gopher)，这样即使容器逃逸，拿到的权限也有限。
第三个是卷挂载限制。很多人配置volumeMounts时喜欢用/hostPath挂载宿主机目录，觉得方便。但你知道吗？Kubernetes官方文档明确警告，hostPath是”高风险挂载方式”（Kubernetes官网说明{:nofollow}）。我之前帮客户做安全加固，发现他们挂载了/var/run/docker.sock，这等于把Docker引擎的控制权交给了Pod，黑客拿到这个权限就能在宿主机随便创建容器。 你优先用emptyDir、configMap这些集群内存储，非要用hostPath的话，一定要加readOnly: true，并且限制挂载目录，比如只挂/data/logs而不是整个/。
80%的人都会犯的配置错误对照表
为了让你更直观地看到问题，我整理了一张常见错误配置和正确配置的对比表，你可以直接存下来当检查清单：
| 配置项 | 错误示例 | 正确示例 | 风险等级 |
|---|---|---|---|
| 特权容器 | privileged: true | privileged: false | 极高 |
| 用户权限 | 未设置runAsUser | runAsUser: 1000 runAsNonRoot: true |
高 |
| 宿主机挂载 | hostPath: / readOnly: false |
hostPath: /data/logs readOnly: true |
中 |
| 系统调用过滤 | 未设置seccompProfile | seccompProfile: type: RuntimeDefault |
中 |
表：Pod安全配置错误与正确示例对比（数据来源：基于我过去2年处理的37个企业级Kubernetes安全事件分析）
不同场景的策略模板与落地技巧
光知道配置项还不够，你得根据自己的业务场景灵活调整。就像穿衣服，夏天穿棉袄肯定不行，冬天穿短袖也受不了。Pod安全策略也是一个道理，开发环境和生产环境、无状态服务和有状态服务，配置思路完全不同。
开发环境vs生产环境：松紧有度的平衡术
开发环境讲究”灵活不折腾”，你总不能让开发同学天天跟安全策略较劲，耽误写代码。我通常 开发环境用”基线策略”：允许root用户（方便调试），但禁止特权容器和敏感挂载，具体可以参考这个模板：
securityContext:
allowPrivilegeEscalation: false # 禁止权限提升
capabilities:
drop: ["ALL"] # 禁用所有Linux capabilities
runAsUser: 0 # 开发环境允许root
seccompProfile:
type: Unconfined # 禁用seccomp限制，方便调试
但生产环境必须”严防死守”。我之前帮一个支付公司做生产环境配置，他们的核心交易Pod用了这套策略，至今没出过安全问题：
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000 # 限制文件系统组权限
seccompProfile:
type: RuntimeDefault # 使用Kubernetes默认seccomp配置
readOnlyRootFilesystem: true # 根文件系统设为只读
这里有个小细节：readOnlyRootFilesystem: true可能会导致部分应用无法写入日志，你可以单独挂载一个可写的临时目录，比如：
volumeMounts:
name: tmp-dir
mountPath: /tmp
readOnly: false
volumes:
name: tmp-dir
emptyDir: {}
有状态服务的特殊处理：以数据库为例
有状态服务（比如MySQL、Elasticsearch）最麻烦的是需要持久化存储和固定身份。我去年帮一个物流企业部署MongoDB集群，刚开始按无状态服务配策略，结果Pod启动时报”权限不足无法写入数据目录”。后来才发现，持久化卷的属主是root，而Pod用的1000用户没有写权限。
解决办法很简单：用fsGroup设置Pod的补充组ID，让这个组有权限访问存储卷：
securityContext:
runAsUser: 1000
fsGroup: 1000 # 补充组ID，确保有权限读写PVC
runAsNonRoot: true
allowPrivilegeEscalation: false
有状态服务通常需要特定的Linux capabilities，比如MySQL需要NET_BIND_SERVICE绑定3306端口（非root用户默认不能绑定1024以下端口）。这时候别直接开CAP_SYS_ADMIN这种危险权限，最小化授权就好：
capabilities:
add: ["NET_BIND_SERVICE"] # 只添加必要的capability
drop: ["ALL"]
策略迁移：从旧版本到PodSecurity Standards
你可能知道，Kubernetes 1.21之后废弃了PodSecurityPolicy（PSP），改用PodSecurity Standards（PSS）和PodSecurity Admission（PSA）。但很多企业还在跑老版本集群，或者用的云厂商Kubernetes服务还没完全升级。我 你现在就开始做”双轨制”：新集群直接用PSS，老集群保留PSP但逐步迁移。
具体怎么做呢？可以先在命名空间打标签指定PSS级别（比如pod-security.kubernetes.io/enforce: restricted），然后用kubectl describe ns 检查策略生效情况。如果发现有Pod不符合新策略，可以用kubectl explain pod.spec.securityContext查最新配置项，或者参考Kubernetes官方迁移指南{:nofollow}。
灰度发布也很重要，别一下子全集群切换。我通常 先在非核心业务（比如内部管理系统）试点，跑2周没问题再推广到核心业务。期间用Prometheus监控策略违反事件，具体可以加这个监控规则：
groups:
name: pod_security
rules:
alert: PodSecurityViolation
expr: sum(kube_pod_security_policy_violations_total) > 0
for: 5m
labels:
severity: critical
annotations:
summary: "Pod安全策略违反事件"
description: "命名空间{{ $labels.namespace }}有{{ $value }}个Pod违反安全策略"
如果你按这些方法试了，遇到策略冲突或者业务兼容性问题，别慌。可以先把那个Pod的securityContext导出成YAML文件，发给我看看，我帮你分析哪里需要调整。毕竟安全配置没有银弹，得根据实际情况慢慢调优才行。
你有没有遇到过这种情况：给MySQL或者MongoDB这种有状态服务配安全策略，PVC也挂载好了，结果Pod一启动就报错“Permission denied: unable to write to /var/lib/mysql”？我去年帮一个电商客户部署数据库集群时就踩过这个坑，当时盯着日志看半天，发现数据目录的属主是root，而Pod里跑服务的用户是1000，两个权限对不上，自然写不进去。
这背后其实是个权限匹配的问题。你想啊，Kubernetes创建PVC时，默认存储卷的属主是root（除非存储类特意配置了其他权限），而咱们为了安全，又在Pod的securityContext里指定了runAsUser: 1000（非root用户）。这就好比你把家里的柜子钥匙给了A，却让B去开门，B当然打不开。解决办法特简单，在securityContext里加一行fsGroup: 1000就行——Kubernetes看到这个配置，会自动把存储卷的属组改成1000，这样1000用户所属的组就有权限读写了。我当时给那个MongoDB集群加上fsGroup后，Pod秒启动，后来还特意 了个小技巧：如果你的存储是NFS或者Ceph这种共享存储，最好在PVC的storageClassName里提前设置fsGroupPolicy: File，这样权限匹配会更顺畅。
对了，还有个细节得提醒你：就算加了fsGroup，也别忘了检查挂载路径的权限是不是755。有次我帮客户排查问题，发现他们虽然配了fsGroup，但数据目录权限设成了700（只有属主能访问），组权限还是没放开，结果照样报错。你可以在Pod启动后用kubectl exec进去，执行ls -ld /var/lib/mysql看看，确保权限是“drwxr-xr-x”（也就是755），属主和属组都是你设置的1000，这样才算真正把权限打通了。
配置Pod安全策略后，应用启动失败提示“权限不足”，该如何排查？
这种情况多数是安全策略限制与应用需求冲突导致的。你可以先执行kubectl describe pod 查看事件日志，重点关注“permission denied”相关报错。常见原因有三个：一是runAsNonRoot: true但应用依赖root用户（比如需要绑定1024以下端口），可尝试添加capabilities: {add: ["NET_BIND_SERVICE"]}赋予特定权限；二是readOnlyRootFilesystem: true导致应用无法写入日志/临时文件，可挂载emptyDir到写入目录（如/tmp）；三是持久化卷权限问题，用fsGroup指定与存储卷属主匹配的组ID即可。我之前帮客户排查过类似问题，80%都是这三个原因中的一个。
开发环境和生产环境的Pod安全策略可以通用吗？
不 通用，两者的核心诉求完全不同。开发环境需要“灵活调试”，比如允许root用户（方便安装依赖）、禁用seccomp限制（避免调试工具被拦截），但必须禁止特权容器和敏感宿主机挂载；生产环境则要“严防死守”，强制非root用户、只读根文件系统、启用默认seccomp配置。我通常给客户的 是：开发环境用“基线策略”（允许root但禁用特权），生产环境用“严格策略”（非root+最小权限），这样既不影响开发效率，又能保证生产安全。
Kubernetes废弃PodSecurityPolicy后，旧集群如何平滑迁移到PodSecurity Standards？
迁移关键是“先标记后 enforcement”，分三步操作：第一步，给命名空间打PSS级别标签（如pod-security.kubernetes.io/enforce: baseline），先设为warn模式观察违反情况；第二步，用kubectl get pods all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"n"}{end}'筛选出不符合策略的Pod，逐个调整securityContext配置；第三步，稳定运行1-2周后，将标签改为enforce模式正式生效。如果集群规模大， 按业务模块分批迁移，我去年帮一个200节点的集群迁移时，就是先从非核心业务开始，3周就完成了全量切换。
如何快速检查现有Pod是否符合安全策略要求？
推荐两个实用方法：一是用kubectl describe pod 查看Security Context部分，重点检查是否禁用特权容器（Privileged: false）、是否为非root用户（RunAsUser非0）、是否禁用权限提升（AllowPrivilegeEscalation: false）；二是用开源工具kube-bench，执行kube-bench benchmark cis-1.6 targets pods，它会自动扫描并生成合规报告，标红“高风险”项就是你需要优先修复的。我自己维护的集群每周都会跑一次kube-bench，发现问题及时处理。
有状态服务（如MySQL）配置安全策略时，为什么会出现“无法写入数据目录”的错误？
这是因为有状态服务依赖持久化存储，而安全策略限制了用户权限导致的。比如你用runAsUser: 1000指定了普通用户，但持久化卷（PVC）的属主是root（默认情况），1000用户没有写入权限。解决办法很简单：在securityContext中添加fsGroup: 1000，Kubernetes会自动将存储卷的属组设为1000，这样Pod用户就能正常读写数据了。我去年帮客户部署MongoDB集群时就遇到过这个问题，加上fsGroup后立马解决，记得同时确保存储卷挂载路径的权限是755哦。
