如何从审计日志中识别K8s权限提升攻击?

开启审计日志不等于能看见权限提升。许多集群的策略停留在 Metadata 级别，日志里只有谁对哪个资源做了什么，一旦真的发生提权，调查者才发现最关键的信息——被授予权限的主体是谁、请求体长什么样——根本没被记录。

权限提升在 Kubernetes 里有几条相对稳定的路径，它们在审计日志里留下的痕迹可以枚举。

最直接的是 RBAC 变更。攻击者拿到低权限凭证后，往往不去猜高权限账号，而是改绑定关系，把自己或自己控制的 ServiceAccount 挂到高权限角色上。roles、rolebindings、clusterroles、clusterrolebindings 的 create、update、patch、delete 因此必须重点盯。只看 verb 和资源名不够，定性信息在 requestObject 里：subjects 指向谁、roleRef 指向哪个角色。这也是这类规则要设到 RequestResponse 级别的原因——Metadata 级别的日志面对一次可疑绑定变更几乎是哑的。

第二条是凭证攫取。Secret 里常躺着各类 token 和密钥，读取本身不是提权，但常是前置动作。判断要看身份：工作负载的 ServiceAccount 读自身命名空间的少量 Secret 属正常，交互式用户身份或跨命名空间批量读取就值得追。相邻的是 pods/exec、attach、portforward，进入一个挂着高权限 ServiceAccount 的 Pod，等于间接拿到它的 token，这类调用同样要留完整请求。

第三条是失败信号的密度。连续 401/403 意味着有人在试错，凭证泄露后的权限探测通常就长这样。另外，集群关掉匿名认证后日志里仍出现 system:anonymous，那不是噪声，是认证被绕过的直接证据。

策略配好只是前提，能不能用取决于误报治理。system: 开头的系统账号会高频读写资源，不排除就会淹没真事件；控制器周期性读 Secret 属于设计行为；生产环境的 kubectl exec 也常是调试。这些都得按身份、按资源、按环境做白名单。新规则先以通知级别跑一段，积累基线再收紧，比一上来就告警更靠谱。

还有一点容易漏：审计日志覆盖的是经过 API 服务器的请求，直接访问 etcd 不在其中。排查提权时把它当唯一证据源，就可能丢掉这条路径。

审计日志要成为调查线索而不是合规摆设，三件事得同时到位——策略级别覆盖到请求体，告警对准上面几条路径，误报治理跟得上。缺任何一环，日志量再大也只是躺在磁盘上的 JSON。