Kubernetes审计日志的最小覆盖面

Kubernetes 审计日志的最小覆盖面，不是记录所有 API 请求，而是确保能够回答四个问题：谁在什么时间、以什么身份、对哪个资源执行了什么操作，以及操作结果如何。覆盖面过窄，无法还原高风险变更；覆盖面过宽，则会增加存储、传输和敏感信息暴露风险。

优先覆盖高风险对象

最小策略应优先覆盖以下资源和动作：

• Secret：读取、创建、修改和删除，重点关注谁获得了敏感配置访问权。
• RBAC 对象：Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的变化，用于追踪权限扩大和高权限绑定。
• 工作负载对象：Pod、Deployment、DaemonSet 的创建与更新，用于定位异常发布、镜像替换和运行参数变更。
• 交互式操作：pods/exec、pods/attach 和 pods/portforward，这些操作可能直接影响运行中的容器。
• 安全边界对象：NetworkPolicy、命名空间、节点以及 API 访问控制相关变更。
• 认证与授权异常：认证失败、权限拒绝和异常权限请求，为检测凭证滥用提供线索。

按风险选择审计级别

Secret 和 RBAC 变更通常至少需要记录元数据，包括请求主体、资源、时间和结果。对 exec、attach、portforward 等交互式操作，可根据调查需求提高记录级别，但不应默认记录所有请求的完整响应。

RequestResponse 能提供更完整的操作内容，却可能把配置中的敏感信息写入审计日志；Metadata 信息较少，但更适合控制日志规模。最小覆盖面的原则是：对高风险行为保留足够的取证字段，对可能泄露 Secret 内容的响应保持克制。

同时，应谨慎处理请求阶段的记录。若已经在后续阶段记录了有效审计事件，可避免重复记录早期请求阶段，以减少无效日志。

覆盖之后还要验证

审计策略上线并不等于审计有效。应执行一次受控的 RBAC 变更和一次受控的 Secret 访问，确认日志能够关联身份、资源、动作和结果；再检查日志是否被发送到受控位置，并具备明确的留存、访问和告警规则。

最终验收标准不是“日志很多”，而是能够及时发现权限扩大、敏感数据访问、异常交互式操作和关键安全边界变更，同时不会因过度记录把敏感内容扩散到审计平台。