Kubernetes审计日志怎么配置，关系到集群安全事件能否被追踪。没有审计日志时，谁读取了Secret、谁修改了RoleBinding、谁创建了特权Pod、谁删除了关键资源，往往只能靠猜。审计日志的价值，是把API访问和资源变更变成可查询、可告警、可复盘的证据链。
这篇文章会把问题放在企业平台和生产环境中讨论，而不是只停留在单个命令或单项配置。你可以把它和Kubernetes安全、Kubernetes最佳实践、云原生安全学习路径配合阅读，先建立整体判断，再回到具体场景设计实施步骤。
本文适用范围
本文讨论Kubernetes API Server审计日志，包括审计策略、事件级别、日志采集、存储、查询和告警。节点系统日志、容器运行时日志和应用日志不在本文重点范围内，但它们可以和审计日志一起用于安全分析。
审计日志记录什么
审计日志记录请求用户、来源、访问资源、动作、命名空间、响应状态和时间等信息。通过这些字段，可以追踪谁在什么时间对什么资源做了什么操作，以及操作是否成功。
审计策略怎么设计
审计策略不应简单记录所有请求，否则日志量会很大且难以分析。建议对高风险资源设置更高审计级别，例如Secret、RoleBinding、ClusterRoleBinding、Pod exec、Webhook、Namespace和Node相关操作。
重点关注哪些行为
安全告警应重点关注读取大量Secret、创建特权Pod、绑定集群管理员角色、修改准入Webhook、删除审计相关资源、异常来源IP访问API Server，以及非预期ServiceAccount访问敏感资源。
采集与存储实践
审计日志应进入集中日志系统，并保留足够时间支持复盘。日志字段要可查询，告警要能定位到用户、资源、命名空间和动作。对于合规场景，还需要保护审计日志本身不被随意删除或篡改。
从日志到治理闭环
审计日志不是只在事故后查看。平台团队可以定期分析高风险权限使用、废弃账号访问、异常失败请求和权限变更频率，用数据反向优化RBAC、准入策略和运维流程。
常见问题
审计日志会不会影响性能？
记录过细可能增加日志量和存储压力，因此需要合理设置审计策略，不建议无差别记录所有请求体。
哪些事件必须重点审计？
Secret读取、权限绑定、特权Pod创建、Webhook变更、Pod exec、节点访问和关键资源删除都应重点关注。
审计日志能替代监控告警吗？
不能。审计日志记录API行为，监控关注资源和运行状态，两者应结合使用。
审计日志需要保存多久？
保存周期取决于合规和安全要求。企业环境通常需要至少覆盖常规安全复盘周期。
小结
Kubernetes审计日志怎么配置的关键，不是把某个功能单独做出来，而是把规则、流程、指标和复盘机制连接起来。对平台团队来说，先明确边界和目标，再逐步自动化，通常比一次性追求复杂能力更稳妥。后续也可以回到相关标签页继续查找更多文章，形成从概念、实践到选型的完整路径。
转载请注明出处：https://www.cloudnative-tech.com/p/8394/
