本文定位：面向已经运行 Kubernetes 集群、希望补齐 API 访问追踪和安全告警能力的运维、安全和平台团队。
Kubernetes审计日志的价值不只是“留一份操作记录”。在真实集群里，几乎所有资源变更都会经过 API Server：谁创建了 ClusterRoleBinding、谁读取了 Secret、哪个 ServiceAccount 频繁删除 Pod、某次准入拒绝由什么配置触发，这些问题都需要审计日志回答。没有审计链路，团队在排查误操作、越权访问和安全事件时只能依赖零散日志；有了审计策略、日志后端和告警规则，集群安全才具备可追踪、可复盘的基础。
如果你还在规划整体安全基线，可以先参考站内的 Kubernetes安全怎么做 建立权限、网络和运行时的全局框架；本文聚焦其中的 API 访问追踪 和 安全告警。
先理解审计日志记录的不是容器日志，而是 API 行为
很多团队初次配置 Kubernetes审计日志时，会把它和应用日志、Pod 日志混在一起。两者关注点完全不同：应用日志回答“业务在容器里发生了什么”，审计日志回答“谁通过 Kubernetes API 做了什么”。
审计日志通常覆盖以下问题：
- 主体：请求来自哪个 user、group、ServiceAccount 或匿名用户。
- 动作：请求使用了 get、list、watch、create、update、patch、delete 还是其他 verb。
- 对象：请求访问了哪个 API group、resource、namespace 和对象名称。
- 来源：请求从哪些 sourceIPs、userAgent 或代理链路进入。
- 结果：API Server 返回了什么状态码，是否被鉴权或准入策略拒绝。
这类信息特别适合处理权限审计、误操作追踪、敏感资源读取分析和安全告警。它不能替代容器运行时日志，也不能直接证明业务数据是否被读取；但它能证明某个主体是否访问过 Kubernetes API 中的对象。
图1：API Server审计事件从请求到告警的流转链路
配置前先确定审计目标，避免一上来全量记录
Kubernetes 支持把审计事件按策略写入后端，但这不意味着应该记录所有请求的完整内容。全量记录看似稳妥，实际可能带来三类问题：日志量暴涨、敏感字段二次暴露、告警规则被噪声淹没。
建议先把目标拆成三层：
- 安全追踪：记录 Secret 读取、RBAC 变更、Pod exec、敏感 namespace 访问等高风险行为。
- 运维复盘：记录工作负载变更、准入拒绝、异常删除和批量操作，便于定位事故责任链。
- 合规留存：按组织要求保留关键 API 行为，并明确日志保存周期、访问权限和脱敏要求。
对于刚开始建设审计能力的团队，优先把高风险操作记录清楚，比追求覆盖所有 API 请求更重要。等日志容量、检索平台和告警流程稳定后，再逐步扩大覆盖范围。
audit-policy 怎么写：用规则分层控制记录级别
Kubernetes 审计策略由一组 rules 组成，API Server 会按顺序匹配。常见审计级别包括 None、Metadata、Request 和 RequestResponse。实际使用时，要把 高价值事件保留足够上下文，把 高频低风险事件降噪。
一个可执行的分层思路如下：
- Secret、ConfigMap 等敏感资源：重点关注 get、list、watch，至少记录 Metadata；如果组织允许且风险可控，可对少量关键场景记录 RequestResponse，但要评估敏感内容二次落盘风险。
- RBAC 对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding 的 create、update、patch、delete 建议保留，便于追踪权限扩大。
- Pod exec、attach、portforward：这些操作往往代表交互式访问，应记录主体、来源和目标对象。
- 高频系统请求：例如部分 watch、lease、节点心跳类请求，通常需要降噪，否则日志量会迅速膨胀。
- 准入拒绝事件：可用于发现不符合安全基线的发布行为，也能反向优化平台模板。
下面是一个简化示例，仅用于说明结构，生产环境应结合集群版本、资源范围和组织策略调整：
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
verbs: ["create", "update", "patch", "delete"]
resources:
- group: "rbac.authorization.k8s.io"
resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
- level: Metadata
verbs: ["get", "list", "watch"]
resources:
- group: ""
resources: ["secrets"]
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
- level: Metadata这段配置体现的是“先保留关键安全事件，再对已知高频系统请求降噪”。不要直接复制到生产集群，应在测试环境验证日志量、字段完整性和告警效果。
图2：审计策略按资源动作主体和级别进行规则匹配
API Server 配置要关注策略文件、后端和轮转
在 kube-apiserver 中启用审计，通常需要指定策略文件和后端参数。不同安装方式的配置入口不同：kubeadm 集群常见做法是修改控制面节点上的静态 Pod manifest；托管 Kubernetes 或平台化集群可能通过控制台、集群配置项或运维接口暴露相关能力。
关键配置项包括：
- –audit-policy-file：指定审计策略文件路径，API Server 必须能读取该文件。
- –audit-log-path：使用 log backend 时指定日志写入路径。
- –audit-log-maxage、–audit-log-maxbackup、–audit-log-maxsize：控制本地审计日志保留周期、备份数量和单文件大小。
- –audit-webhook-config-file：使用 webhook backend 时指定投递配置。
- –audit-webhook-batch-max-size 等批量参数：用于控制事件批量发送行为，需结合后端吞吐能力调优。
如果使用本地文件后端，必须同时设计日志采集和轮转，否则控制面磁盘可能被审计日志打满。如果使用 webhook 后端，要关注后端不可用时的队列、丢弃策略和延迟，避免审计链路反过来影响控制面稳定性。
日志字段怎么读：从 user、verb、objectRef 和 responseStatus 入手
Kubernetes 审计事件是结构化数据。初期排查不需要记住所有字段，先抓住几个高价值字段即可。
| 字段 | 作用 | 排查价值 |
|---|---|---|
| user.username | 请求主体 | 判断是人、组件还是 ServiceAccount |
| verb | 请求动作 | 区分读取、变更、删除和交互式访问 |
| objectRef.resource | 资源类型 | 判断是否访问 Secret、RBAC、Pod 等敏感对象 |
| objectRef.namespace | 命名空间 | 定位影响范围和租户边界 |
| sourceIPs | 来源地址 | 排查异常来源、代理链路或跳板机 |
| userAgent | 客户端类型 | 区分 kubectl、控制器、脚本或自动化平台 |
| responseStatus.code | 返回状态码 | 判断请求成功、拒绝或异常 |
字段组合比单个字段更适合告警
单独看到一次 get secrets 不一定代表泄露，可能是控制器的正常同步；但如果“非常用 ServiceAccount + 跨 namespace + 高频 list secrets + 非预期 sourceIP”同时出现，就值得提升优先级。审计告警应尽量基于字段组合，而不是单个字段命中。
安全告警实践：从高置信度规则开始
审计日志进入日志平台、SIEM 或安全运营平台后，就可以建立告警规则。建议从误报较低、处置动作明确的规则开始，不要一开始就把所有 create/update/delete 都推成告警。
优先落地的规则包括：
- 异常读取 Secret：非预期用户或 ServiceAccount 读取敏感 namespace 中的 Secret。
- 权限突然扩大：创建或修改 ClusterRoleBinding，尤其是绑定到 cluster-admin 一类高权限角色。
- 交互式进入容器：生产 namespace 中的 pods/exec、attach、portforward 操作。
- 批量删除资源：短时间内删除大量 Pod、Deployment、Namespace 或关键配置。
- 准入策略连续拒绝：同一流水线或用户频繁触发安全基线拒绝，可能说明模板或流程存在问题。
告警内容不要只写“触发规则”。至少要包含主体、动作、资源、命名空间、来源、响应状态和建议处置动作。否则值班人员仍要回到日志平台重新拼上下文。
图3：审计日志从采集解析到告警处置和复盘的闭环流程
常见误区：审计日志能追踪，但不能替你做授权设计
Kubernetes审计日志是观察和追踪能力，不是权限控制本身。如果 RBAC 已经过宽，审计日志最多告诉你“谁使用了过大的权限”，不能自动阻止这类权限被滥用。权限收敛仍要回到 RBAC、准入控制、网络隔离和多租户边界设计。
在平台建设阶段，审计日志最好与权限模型一起设计。比如在规划多团队平台时，可以结合 Kubernetes平台建设怎么规划 中的平台边界，把审计规则按团队、命名空间和角色分层；在选择集群管理能力时，也可以参考 集群管理工具怎么选 中的多集群纳管、权限和可观测要求。
上线前检查清单
审计能力上线前至少检查：
- 策略文件有效：audit-policy 使用受支持的 apiVersion，API Server 启动后没有配置错误。
- 日志能写入：本地文件或 webhook 后端能稳定接收事件。
- 容量可控：已配置轮转、保留周期、磁盘监控或后端吞吐监控。
- 敏感内容可控：避免不必要地记录 RequestResponse，防止 Secret 内容在日志中二次暴露。
- 告警可处置：每条高优先级告警都有责任人、判断依据和处置步骤。
- 权限受控：审计日志本身只允许安全和平台相关角色访问。
小结
Kubernetes审计日志配置的核心，不是打开一个开关，而是设计一条从 API 请求、审计策略、日志后端到安全告警的完整链路。实践中建议先明确审计目标，再用 audit-policy 分层记录关键事件；后端配置要兼顾稳定性、容量和检索能力；告警规则应从 Secret 读取、RBAC 变更、交互式访问和批量删除等高风险场景切入。只要这条链路持续运行并能复盘优化，审计日志就会从“事后留痕”变成集群安全治理的一部分。
FAQ
Kubernetes审计日志会记录容器里的业务访问吗？
不会。它记录的是对 Kubernetes API Server 的请求行为，例如创建 Deployment、读取 Secret、执行 pods/exec。业务系统内部的 HTTP 请求、数据库访问或应用错误，需要通过应用日志、服务网格访问日志或 APM 工具观察。
Kubernetes审计日志是否应该记录 RequestResponse？
不建议默认全量使用。RequestResponse 会记录请求和响应体，信息更完整，但也可能带来日志量增长和敏感内容落盘风险。更稳妥的做法是对少量高价值、低频且可控的场景启用，并配合访问权限和保留周期管理。
审计日志很多，告警误报高怎么办？
先不要扩大规则范围，而是把告警拆成“立即处置、二次确认、仅入库分析”三类。高优先级规则应基于字段组合，例如主体、资源、动作、来源和 namespace 同时异常；对于系统组件的高频请求，要通过 audit-policy 或告警白名单降噪。
托管 Kubernetes 不能改 API Server 参数怎么办？
托管集群通常不允许直接修改控制面启动参数。可以先查看云厂商或平台是否提供审计日志开关、日志服务投递或控制面审计能力。如果只能获取部分审计数据，应明确覆盖范围，并用 RBAC 审计、准入策略日志和平台操作日志补充。
审计日志保留多久合适？
保留周期取决于组织合规要求、事件响应窗口、日志成本和敏感性。常见做法是把高价值安全事件保留更久，把高频低风险事件保留较短，并确保历史日志可检索、可导出、访问受控。不要只设置保留天数，还要验证容量和检索性能。
权威参考资料
- Kubernetes 官方文档：Auditing
- Kubernetes 官方文档：kube-apiserver 参数参考
- Kubernetes 官方文档：Authorization Overview
- Kubernetes 官方文档：API Access Control
