K8s审计日志怎么配置？详解Kubernetes审计策略与日志采集方法

Kubernetes集群的API Server是所有资源操作的唯一入口，无论是kubectl命令、控制器调谐还是第三方系统的调用，最终都会转化为对API Server的REST请求。审计日志的作用就是把这些请求完整地记录下来，形成一条可追溯的操作链条。在安全审计、故障排查、合规检查等场景中，这套日志几乎是唯一可靠的证据来源。本文将围绕审计策略的编写、API Server的启动配置以及日志的采集与分析展开，给出一套可直接落地的配置方案。

审计日志的基本工作原理

审计功能由kube-apiserver内置，当请求到达API Server后，会经过认证、授权、准入控制等阶段，每个阶段都会产生一个审计事件。这些事件随后被分发给已配置的审计后端，常见的后端有日志后端（log backend）和 webhook 后端两种。日志后端将事件以JSON格式写入本地文件或标准输出，webhook后端则把事件推送到外部服务。

每个审计事件包含了丰富的上下文信息，例如请求者的用户名、所属用户组、请求的Verb（如get、create、delete）、资源类型、命名空间、请求与响应的状态码、来源IP等。理解这些字段对后续编写策略和排查问题非常重要。一个典型的审计事件结构大致如下：

{
  "level": "Metadata",
  "auditID": "3f2a1b8c-xxxx",
  "verb": "create",
  "user": {
    "username": "system:admin",
    "groups": ["system:masters"]
  },
  "resource": "pods",
  "namespace": "default",
  "requestURI": "/api/v1/namespaces/default/pods",
  "responseStatus": {
    "code": 201
  },
  "sourceIPs": ["192.168.1.100"]
}

编写审计策略文件

审计策略是一个YAML文件，通过rules字段定义一组规则，API Server按顺序匹配，命中第一条规则后停止。策略中不匹配任何规则的请求将按预定义策略处理，默认级别为None，也就是不记录，这一点经常被忽略导致日志缺失。策略文件的顶层结构如下：

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods"]
  - level: Metadata
    resources:
      - group: "apps"
        resources: ["deployments"]
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch", "list"]

审计级别决定了记录信息的详细程度，共有四个等级。None表示不记录；Metadata只记录请求的元信息，不含请求体和响应体，这是最常用的级别，日志量小且包含关键字段；Request在Metadata基础上记录请求体，适合记录资源创建和修改操作；RequestResponse则把响应体也一并记录，日志量最大，一般只对ConfigMap、Secret之外的敏感资源配置，因为Secret内容会被完整记录在日志中，带来泄露风险。

编写规则时建议遵循“先细后粗”的原则：把需要详细记录的操作放在前面，把高频低价值的请求（如kubelet的心跳、探针访问）放在后面用None级别排除，最后兜底一条Metadata规则。这样既能保证关键操作可追溯，又能控制日志规模。omitStages字段用于跳过某些审计阶段的记录，把RequestReceived排除掉可以减少近一半的事件量，因为每个请求会在执行阶段再记录一次更完整的事件。

在kube-apiserver中启用审计功能

策略文件写好后，需要通过kube-apiserver的启动参数启用审计。对于kubeadm部署的集群，修改/etc/kubernetes/manifests/kube-apiserver.yaml这个静态Pod清单即可，修改后kubelet会自动重建API Server Pod。需要添加的关键配置如下：

command:
  - kube-apiserver
  - --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/audit/audit.log
  - --audit-log-maxage=30
  - --audit-log-maxbackup=10
  - --audit-log-maxsize=100
  - --audit-log-format=json
volumeMounts:
  - name: audit-policy
    mountPath: /etc/kubernetes/audit
    readOnly: true
  - name: audit-log
    mountPath: /var/log/kubernetes/audit
volumes:
  - name: audit-policy
    hostPath:
      path: /etc/kubernetes/audit
      type: DirectoryOrCreate
  - name: audit-log
    hostPath:
      path: /var/log/kubernetes/audit
      type: DirectoryOrCreate

各参数的含义需要清楚：audit-policy-file指定策略文件路径，必须挂载进容器内；audit-log-path为日志输出路径，设置为减号时输出到标准输出；三个max参数分别控制日志保留天数、最多备份文件数和单个文件的最大MB数，达到上限后触发轮转；audit-log-format支持json和legacy，推荐json格式便于程序解析。

如果集群由托管服务提供（如云厂商的托管集群），通常在控制面管理界面中直接配置审计策略，无需手工修改API Server参数。对于二进制方式部署的集群，则直接编辑systemd单元文件中的启动参数并重启服务。无论哪种方式，修改后务必通过查看日志文件或执行一次kubectl操作验证审计事件是否正常生成。

日志轮转与采集分析实践

审计日志增长速度很快，一个中型集群每天产生数GB并不罕见。除了内置的轮转参数，还可以配合logrotate或依赖日志采集组件处理。生产环境推荐使用Fluent Bit或Filebeat采集审计日志并投递到ES、Loki等存储中，配合Grafana做可视化查询。下面是一段Fluent Bit的采集配置示例：

[INPUT]
    Name              tail
    Path              /var/log/kubernetes/audit/audit.log
    Tag              kube.audit
    Parser            json
    Refresh_Interval  10

[OUTPUT]
    Name              es
    Match             kube.audit
    Host              192.168.0.1
    Port              9200
    Index             k8s-audit
    Logstash_Format   On

在分析层面，几类查询场景值得提前规划：一是按用户名过滤，快速定位某人的所有操作；二是按resource和verb组合查询，例如谁删除了某个Deployment；三是按responseStatus.code过滤4xx和5xx，发现异常的越权尝试。审计事件中的auditID字段是全局唯一标识，可以用来串联一次请求的多个阶段事件，排查问题时非常实用。

最后提醒几个常见的坑：策略文件语法错误会导致API Server启动失败，修改后建议先用干跑方式验证；对Secret配置RequestResponse级别会把敏感凭据写入日志，务必评估合规要求后再决定；审计日志本身也是敏感数据，存储和传输环节应做好访问控制与加密。一套配置合理的审计体系，配合集中化的日志平台，才能让集群的操作轨迹真正可查、可审、可溯源。

Kubernetes审计日志audit policyK8s安全修改时间：2026-09-15 07:58:29