k8s之审计日志
一、为什么要有审计
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 等敏感接口,根据读写记录相应的请求体和返回体。