一、为什么要有审计
Kube-Apiserver 的负载突然变高，大量访问失败，集群中到底发生了什么？
当集群发生问题时，这是Metric一般会失效，为了排查以上问题，k8s 提供了两种原生的日志形式——审计（Audit）和事件（Event），它们分别记录了对于集群资源的访问以及集群中发生的事件信息。
二、审计日志简介
k8s在 v1.7 版本中发布了审计（Audit）日志功能，审计（Audit）提供了时序操作记录（包括时间、来源、操作结果、发起操作的用户、操作的资源以及请求/响应的详细信息等）。
K8s 中的审计日志是标准的 JSON 格式，APIServer 会根据具体的日志策略将对应的审计日志保存本地，并可以设置最大保存周期、时间、轮转策略等，一般在/var/log/kube-apiserver目录下。可以参考Audit官方文档（https://kubernetes.io/docs/tasks/debug-application-cluster/audit/）
三、审计来源
在 k8s中，所有对集群状态的查询和修改都是通过向 Apiserver 发送请求，对 Apiserver 的请求来源可以分为 4类：
-
控制面组件，例如 Scheduler，各种 Controller，Apiserver 自身
-
节点上的各种 Agent，例如 Kubelet、Kube-proxy 等
-
集群的其它服务，例如 Coredns、Ingress-controller、各种第三方的 Operator 等
-
外部用户，例如运维人员通过 Kubectl
四、审计日志格式
每一条审计日志都是一个 JSON 格式的结构化记录，包括元数据（metadata）、请求内容（requestObject）和响应内容（responseObject）3个部分。其中元数据一定会存在，请求和响应内容是否存在取决于审计级别。
日志记录阶段
审计日志根据日志策略可以选择在事件执行的某个阶段记录，目前支持的事件阶段有：
-
RequestReceived- 接收到事件且在分配给对应 handler 前记录; -
ResponseStarted- 开始响应数据的 Header 但在响应数据 Body 发送前记录，这种一般应用在持续很长的操作事件，例如 watch 操作; -
ResponseComplete- 事件响应完毕后记录; -
Panic- 内部出现 panic 时记录。
日志记录等级
审计日志根据日志策略可以选择事件保存的等级，根据等级不同，APIServer 记录日志的详细程度也不同。目前支持的事件等级有：
-
None- 不记录日志; -
Metadata- 只记录 Request 的一些 metadata (例如 user, timestamp, resource, verb 等)，但不记录 Request 或 Response 的 body; -
Request- 记录 Request 的 metadata 和 body; -
RequestResponse- 最全记录方式，会记录所有的 metadata、Request 和 Response 的 body。
日志记录策略
APIServer 支持对每类不同的资源设置不同的审计日志策略，包括日志记录阶段以及日志记录等级，一般都遵循以下原则：
-
在收到请求后不立即记录日志，当返回体 header 发送后才开始记录;
-
对于大量冗余的 kube-proxy watch 请求，kubelet 和 system:nodes 对于 node 的 get 请求，kube 组件在 kube-system 下对于 endpoint 的操作，以及 apiserver 对于 namespaces 的 get 请求等不作审计;
-
对于/healthz_，/version_, /swagger*等只读 url 不作审计;
-
对于可能包含敏感信息或二进制文件的 secrets，configmaps，tokenreviews 接口的日志等级设为 metadata，该 level 只记录请求事件的用户、时间戳、请求资源和动作，而不包含请求体和返回体;
-
对于一些如 authenticatioin、rbac、certificates、autoscaling、storage 等敏感接口，根据读写记录相应的请求体和返回体。
