审计日志与策略扫描如何互补?

我最近在帮朋友排查一个生产集群的安全问题时，被一个挺尴尬的场景整不会了：明明策略扫描显示某个 Pod 带着 hostPath 卷，可我们翻遍变更记录，就是找不到是谁、什么时候改的。那一刻我突然意识到，手里只有扫描结果，就像拿到了一张“当前很危险”的照片，却不知道凶手是谁。后来我把审计日志和策略扫描放在一起看，才真正把这个问题解开了。

这两样东西其实是互补的，缺一个都不行。策略扫描回答的是“现在离基线有多远”，它给你一个全貌：哪个命名空间的 NetworkPolicy 被删了、哪个 Pod 的 securityContext 不对劲。但扫描结果不会告诉你“谁干的”——它只给你看结果，不给你看过程。审计日志恰恰补上这一环，它记录的是“谁在什么时候用什么命令改了什么东西”，把 patch、update 这些写操作连同请求体都留下来。只看审计日志也有盲区：你看到有人 patch 了一个 Deployment，但不知道这个 patch 之后整个命名空间的暴露面变成了什么样，也不知道这个改动是不是让基线彻底失效了。

我自己的经验是，把两者结合起来用，效果才是最好的：扫描负责把“漂移”变成证据，审计负责给证据配上“作案时间线”。比如扫描发现某个 Pod 有 hostNetwork: true，我就能去审计日志里按时间倒查，找到是哪条 kubectl 命令、哪个账号把它带进来的。这种“先有结论、再找原因”的路径，比对着日志瞎猜高效太多了。

实际操作上，有一个小技巧特别值得分享：审计策略不用把什么都记下来，那样日志会爆炸。把安全敏感对象的写操作记到 Request 级别就够了，重点盯 pods、deployments、networkpolicies、rolebindings 这些对象。策略扫描这边，先跑 audit 模式把违规对象列出来，别一上来就 enforce 拦截，否则容易把正常发布卡住。等存量问题清得差不多了，再考虑收紧。

还有一个让我印象深刻的点：降噪。审计日志和扫描结果直接转发给值班同学，大概率没人看。我们后来维护了一份“字段白名单”，只对 securityContext、hostNetwork、hostPath、NetworkPolicy 规则这些敏感字段的变化告警，同一对象短时间内多次 patch 合并成一条事件。这样告警量一下子降下来了，而且每条告警都值得看。区分“已授权变更”和“漂移”也很关键，来自 CI 账号且带审批标签的改动降为记录，个人账号在发布窗口外直接 edit 才升级为告警。

说到底，扫描给你的是“现状快照”，审计给你的是“变更轨迹”。单看任何一边，都只能看到一半的故事。把两边对起来看，你才能既知道集群现在安不安全，也知道它是怎么变成这样的——这个“怎么变的”，才是后续修复和防复发最值钱的线索。