Kubernetes为了加强对集群操作的安全监管，从1.4版本开始引入审计机制，主要体现为审计日志（Audit Log）。审计日志按照时间顺序记录了与安全相关的各种事件，这些事件有助于系统管理员快速、集中了解发生了什么事情、作用于什么对象、在什么时间发生、谁（从哪儿）触发的、在哪儿观察到的、活动的后续处理行为是怎样的，等等。
下面是两条Pod操作的审计日志示例。
第1条：
第2条：
API Server把客户端的请求（Request）的处理流程视为一个“链条”，这个链条上的每个“节点”就是一个状态（Stage），从开始到结束的所有Request Stage如下。
◎ RequestReceived：在Audit Handler收到请求后生成的状态。
◎ ResponseStarted：响应Header已经发送但Body还没有发送的状态，仅对长期运行的请求（Long-running Requests）有效，例如Watch。
◎ ResponseComplete：Body已经发送完成。
◎ Panic：严重错误（Panic）发生时的状态。
Kubernets从1.7版本开始引入高级审计特性（AdvancedAuditing），可以自定义审计策略（选择记录哪些事件）和审计后端存储（日志和Webhook）等，开启方法为增加kube-apiserver的启动参数--feature-gates=AdvancedAuditing=true。注意：在开启AdvancedAuditing后，日志的格式有一些修改，例如新增了上述Stage信息；从Kubernets 1.8版本开始，该参数默认为true。
如图10.19所示，kube-apiserver在收到一个请求后（如创建Pod的请求），会根据Audit Policy（审计策略）对此请求做出相应的处理。
图10.19 基于审计策略记录审计日志
我们可以将Audit Policy视作一组规则，这组规则定义了有哪些事件及数据需要记录（审计）。当一个事件被处理时，规则列表会依次尝试匹配该事件，第1个匹配的规则会决定审计日志的级别（Audit Level），目前定义的几种级别如下（按级别从低到高排列）。
◎ None：不生成审计日志。
◎ Metadata：只记录Request请求的元数据如requesting user、timestamp、resource、verb等，但不记录请求及响应的具体内容。
◎ Request：记录Request请求的元数据及请求的具体内容。
◎ RequestResponse：记录事件的元数据，以及请求与应答的具体内容。
None以上的级别会生成相应的审计日志并将审计日志输出到后端，当前的后端实现如下。
（1）Log backend：以本地日志文件记录保存，为JSON日志格式，我们需要对API Server的启动命令设置下列参数。
◎ --audit-log-path：指定日志文件的保存路径。
◎ --audit-log-maxage：设定审计日志文件保留的最大天数。
◎ --audit-log-maxbackup：设定审计日志文件最多保留多少个。
◎ --audit-log-maxsize：设定审计日志文件的单个大小，单位为MB，默认为100MB。
审计日志文件以audit-log-maxsize设置的大小为单位，在写满后，kube-apiserver将以时间戳重命名原文件，然后继续写入audit-log-path指定的审计日志文件；audit-log-maxbackup和audit-log-maxage参数则用于kube-apiserver自动删除旧的审计日志文件。
（2）Webhook backend：回调外部接口进行通知，审计日志以JSON格式发送（POST方式）给Webhook Server，支持batch和blocking这两种通知模式，相关配置参数如下。
◎ --audit-webhook-config-file：指定Webhook backend的配置文件。
◎ --audit-webhook-mode：确定采用哪种模式回调通知。
◎ --audit-webhook-initial-backoff：指定回调失败后第1次重试的等待时间，后续重试等待时间则呈指数级递增。
Webhook backend的配置文件采用了kubeconfig格式，主要内容包括远程审计服务的地址和相关鉴权参数，配置示例如下：
--audit-webhook-mode则包括以下选项。
◎ batch：批量模式，缓存事件并以异步批量方式通知，是默认的工作模式。
◎ blocking：阻塞模式，事件按顺序逐个处理，这种模式会阻塞API Server的响应，可能导致性能问题。
◎ blocking-strict：与阻塞模式类似，不同的是当一个Request在RequestReceived阶段发生审计失败时，整个Request请求会被认为失败。
（3）Batching Dynamic backend：一种动态配置的Webhook backend，是通过AuditSink API动态配置的，在Kubernetes 1.13版本中引入。
需要注意的是，开启审计功能会增加API Server的内存消耗量，因为此时需要额外的内存来存储每个请求的审计上下文数据，而增加的内存量与审计功能的配置有关，比如更详细的审计日志所需的内存更多。我们可以通过kube-apiserver中的--audit-policy-file参数指定一个Audit Policy文件名来开启API Server的审计功能。如下Audit Policy文件可作参考：
对于审计日志的采集和存储，一种常见做法是，将审计日志以本地日志文件方式保存，然后使用日志采集工具（例如Fluentd）采集该日志并存储到Elasticsearch中，用Kibana等UI界面对其进行展示和查询。另一种常见做法是用Logstash采集Webhook后端的审计事件，通过Logstash将来自不同用户的事件保存为文件或者将数据发送到后端存储（例如Elasticsearch）。