Kubernetes审计日志不是把所有请求都写下来，而是按安全价值记录关键操作并接入可检索、可告警的链路。
自建集群、托管集群和发行版集群的API Server配置方式不同。动手前要确认audit policy文件位置、参数注入方式、日志落盘路径、采集Agent和回滚方法。
相关主题可以结合 Kubernetes、AI基础设施、云原生安全 和 GPU调度 等站内内容一起阅读。
1. 配置前先确认控制面入口
自建集群、托管集群和发行版集群的API Server配置方式不同。动手前要确认audit policy文件位置、参数注入方式、日志落盘路径、采集Agent和回滚方法。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
2. audit policy要分层设计
普通读请求可以记录Metadata，权限变更和关键资源变更建议记录Request，少量调查场景再临时提高到RequestResponse。长期记录过多细节会带来存储压力，也可能暴露敏感字段。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
3. 先从高价值事件开始
建议优先覆盖Secret访问、ServiceAccount变更、RoleBinding和ClusterRoleBinding变更、删除操作、准入失败和异常用户来源。这些事件对追踪越权和误操作最有价值。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
4. 采集链路要保留关键字段
日志进入检索系统后，要能按用户、资源、动词、命名空间、源IP、响应码和时间窗口过滤。如果采集时丢字段，后续告警和取证都会变得困难。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
示例策略片段可以先从高价值资源开始：
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: Request
verbs: ["create", "update", "patch", "delete"]5. 告警规则要结合上下文
不要把所有delete或patch都设为高危。更可靠的方式是结合主体、资源、命名空间、时间窗口和变更来源判断风险。CI发布窗口内的操作和个人账号深夜创建高权限绑定，风险含义完全不同。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
6. 上线后做一次演练
可以创建临时RoleBinding、读取测试Secret、触发一次准入拒绝，再确认日志平台能检索、告警能触达、通知内容足够定位。
每一步都要保留验证命令和回滚入口，避免配置成功但不可运营。
深入落地说明
1. 策略文件的维护方式
审计策略不建议长期由单个管理员手工维护。更稳妥的做法是把audit policy纳入版本管理，记录每次规则调整的原因、影响资源和预期日志量。这样出现日志爆增或字段缺失时，可以快速回溯变更。
策略变更前最好先在测试集群验证。重点观察API Server负载、日志大小、采集延迟和字段完整性，确认没有明显副作用后再进入生产。
2. 哪些事件值得提高记录级别
高价值事件通常集中在权限、密钥、删除和准入失败。比如创建ClusterRoleBinding、读取Secret、删除Namespace、绕过准入策略，这些事件比普通list请求更适合提高记录级别。
记录级别越高，日志体积和敏感信息风险越大。RequestResponse不适合长期覆盖大范围资源，除非团队已经明确存储成本、脱敏策略和访问权限。
3. 采集链路的字段检查
日志进入检索系统后，要抽样检查user、verb、resource、namespace、sourceIPs、responseStatus、requestURI等字段是否完整。缺少这些字段，安全人员只能看到事件存在，却无法快速定位责任主体。
还要检查时间字段是否统一。控制面、采集Agent和日志平台时间不一致，会影响事件排序，也会影响告警窗口判断。
4. 告警分级不要过粗
审计告警可以分为提醒、调查和紧急三类。普通权限变更可以进入提醒，高权限绑定或敏感资源访问进入调查，异常主体在非变更窗口操作关键资源才进入紧急。
分级过粗会让所有事件都涌入同一个通知渠道，最终导致安全人员忽略告警。告警规则要配合静默、抑制和白名单，但白名单必须定期复核。
5. 审计演练怎么做
建议每季度做一次小型演练：创建临时高权限绑定，读取测试Secret，触发一次准入拒绝，再检查日志检索、告警通知和处置记录是否完整。
演练结果要形成整改项。例如告警缺少命名空间、通知没有负责人、日志查询语句难以复用，这些问题都应进入后续优化。
上线步骤：审计日志从配置到响应
- 确定范围：先覆盖权限变更、Secret访问、删除操作、准入失败和异常来源，不把所有请求都提升到高记录级别。
- 版本化策略：把audit policy放入版本管理，记录每次调整的原因、预估日志量和回滚方式。
- 接入采集：确认日志进入检索系统后字段完整，至少能按用户、动作、资源、命名空间和时间过滤。
- 配置告警：把高风险操作、异常主体和非变更窗口操作分级通知，不让所有事件进入同一告警渠道。
- 定期演练：通过临时权限绑定、测试Secret读取和准入拒绝验证日志、告警和处置流程。
教程类内容需要让读者知道每一步的验证点。审计日志的价值不在于文件是否生成，而在于安全人员能否用它追踪和响应真实事件。
场景化展开：审计日志要服务真实响应流程
1. 审计范围先覆盖高风险动作
Kubernetes审计日志如果一开始就记录所有请求，日志量会快速膨胀，安全团队反而难以找到重点。更实用的起点是覆盖权限变更、Secret读取、删除资源、准入拒绝、异常来源和集群级对象修改。这些动作和安全事件、误操作、越权访问的关系更直接，也更适合作为告警和复盘入口。
策略文件需要和变更流程绑定。每次增加记录级别，都要说明原因、预计日志增量、保留周期和回滚方式。否则审计策略会不断膨胀，最后既影响存储成本，也让检索性能下降。
2. 字段完整性比日志数量更重要
审计日志的价值不在于文件存在，而在于能否回答问题：谁在什么时间对哪个命名空间的什么资源做了什么动作，结果是允许、拒绝还是失败。采集到检索系统后，需要确认用户、用户组、verb、resource、namespace、requestURI、sourceIPs、responseStatus等字段都能被过滤和聚合。
如果字段在采集中被截断或改名，响应时就会出现断点。建议用几类测试事件验证链路，例如临时绑定高权限、读取测试Secret、删除测试ConfigMap、触发准入拒绝。每个事件都要能在检索系统中按固定字段找到。
3. 告警要分层，不要把所有事件推给同一群人
审计告警如果不分级，很容易形成噪音。删除普通Pod、修改ClusterRole、读取Secret和准入策略拒绝，风险等级并不相同。可以把事件分成提示、需要确认、需要立即响应三类，并分别路由到发布负责人、平台值班或安全团队。
同时要把审计事件和工单、发布窗口、应急授权关联起来。变更窗口内的高风险动作可以要求确认，非变更窗口的同类动作则需要升级通知。这样审计日志才不只是事后查看，而能进入真实的安全响应流程。
4. 保留样例查询，方便值班复用
审计日志上线后，建议沉淀几组固定查询：最近一小时读取Secret的主体、修改RBAC的用户、删除生产命名空间资源的请求、被准入策略拒绝的镜像、来自异常来源地址的API访问。这些查询可以写进值班手册，避免事件发生时临时拼字段。
查询模板还应配合响应动作，例如确认是否有工单、联系资源负责人、冻结异常账号或回滚权限绑定。这样审计日志才能从数据沉淀进入处置流程。
落地检查清单
- 先确认本文讨论的问题是否就是当前团队的主要矛盾。
- 再检查现有平台、流程和人员职责是否支持这些动作。
- 最后用小范围验证替代一次性大改，保留回滚窗口和复盘记录。
小结
Kubernetes审计日志配置实战：策略、采集与告警 的重点，是把读者正在搜索的问题落到真实场景、判断口径和执行顺序中。内容不应该停留在概念解释，也不应该把所有场景压成同一种答案。
发布和复盘时，可以重点检查三件事：标题承诺是否被正文兑现，图表是否帮助读者理解关键链路，FAQ是否回答了真实疑问。
常见问题
1. 这类问题应该先看工具还是先看场景？
建议先看场景。工具能力只有放到团队规模、业务风险、现有平台和运维流程中，才知道是否真的适合。
2. 如果测试环境能跑通，是否可以直接上生产？
不建议。生产环境还要验证权限、观测、告警、回滚、容量和多人协作流程，否则上线后问题会集中暴露。
3. 如何判断这篇文章中的方法是否适合自己的团队？
可以从目标、约束和验证成本三方面判断：目标是否一致，约束是否相近，是否能用小范围实验验证结论。
