审计日志与etcd访问追踪的边界在哪里

大家聊 Kubernetes 安全的时候，经常会听到审计日志和 etcd 访问追踪这两个词，很多人以为它们是一回事，或者觉得开了审计日志就等于把集群里所有动静都盯住了。实际上，这俩的边界比想象中清楚得多，搞混了容易在排查问题的时候白费力气。

审计日志追踪的是“谁通过 API 服务器做了什么”。所有经过 kube-apiserver 的请求，不管是 kubectl 命令、控制器、调度器，还是业务组件通过 ServiceAccount 发起的调用，都会被记录下来。它回答的是四个问题：谁发起的、做了什么操作、什么时间、针对什么资源。但关键在于，如果有人在 etcd 层面直接访问数据，审计日志是看不见的。etcd 的访问追踪得靠它自己的日志和 TLS 客户端证书审计来覆盖。简单说，审计日志管的是“前台”的访问记录，etcd 那边属于“后台”的直连通道，两条线不能混为一谈。

这个边界在实际排查时特别容易踩坑。比如集群里出现了异常数据变更，大家第一反应都是去翻审计日志，结果发现记录里干干净净，就以为没问题。实际上攻击者如果拿到了 etcd 的访问凭证，完全可以绕过 API 服务器直接读写数据，这时候审计日志就是盲区。所以判断一个集群的安全能力，不能只看审计日志配没配，还得看 etcd 那一层的访问控制有没有做好，两边是互补的关系，不是替代关系。

再往细看，审计日志本身的配置也影响它能覆盖到什么程度。默认的 Metadata 级别只能记录谁在什么时间对什么资源做了什么，看不到请求体和响应体。如果安全调查需要知道某次 Secret 读取具体返回了什么内容，就得对敏感资源单独配置 RequestResponse 级别。很多人配置完策略发现日志里信息不全，多半就是级别没设对。这里有个容易忽略的细节，requestObject 字段只在 Request 及以上级别出现，responseObject 只在 RequestResponse 级别出现，日志里缺字段，先检查策略级别，别急着怀疑日志采集链路出了问题。

告警规则的构建也得基于这个边界来设计。审计日志能告警的是 API 层面的异常行为，比如匿名访问、RBAC 权限变更、Secret 批量读取、pods/exec 调用、大量 403/401 响应。这些规则能覆盖大多数通过 API 发起的攻击路径。但如果是 etcd 层面的异常访问，审计日志的告警规则是感知不到的，那需要另外一套监控手段。所以设计安全告警体系的时候，心里要有这张地图：哪些风险靠审计日志覆盖，哪些风险得靠 etcd 层面的日志和证书审计来兜底。

对普通团队来说，最实际的建议是先把审计日志配好，至少做到“谁在什么时间对什么资源做了什么”能查得到，然后对 Secret、RBAC 配置、Pod 执行类操作这些高风险对象提高记录级别。同时心里清楚，这层防护只覆盖 API 通道，etcd 的访问控制和安全审计是另一道独立防线，别指望一份日志解决所有问题。边界清楚了，排查思路才不会乱。