kube-apiserver审计日志记录和采集

ゝ一纸荒年。 2023-06-08 10:49 18阅读 0赞

Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。它能帮助集群管理员处理以下问题：

*  发生了什么？
 *  什么时候发生的？
 *  谁触发的？
 *  为什么发生？
 *  在哪观察到的？
 *  它从哪触发的？
 *  它将产生什么后果？

Kube-apiserver 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。

每个请求都可以用相关的 “stage” 记录。已知的 stage 有：

*  \*\*RequestReceived -\*\*事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。
 *  **ResponseStarted -** 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。
 *  **ResponseComplete -** 当响应消息体完成并且没有更多数据需要传输的时候。
 *  **Panic -** 当 panic 发生时生成。

**Note:**

审计日志记录功能会增加 API server的内存消耗，因为需要为每个请求存储审计所需的某些上下文。此外，内存消耗取决于审计日志记录的配置。

## 审计策略 ##

审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 \[审计级别\]\[auditing-level\]。已知的审计级别有：

\*\*None -\*\*符合这条规则的日志将不会记录。

\*\*Metadata -\*\*记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。

\*\*Request -\*\*记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。

\*\*RequestResponse -\*\*记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。

您可以使用 --audit-policy-file 标志将包含策略的文件传递给 kube-apiserver。如果不设置该标志，则不记录事件。注意 rules 字段必须在审计策略文件中提供。

以下是一个审计策略文件的示例：

audit/audit-policy.yaml

apiVersion: audit.k8s.io/v1beta1 # This is required.
    kind: Policy
    # Don't generate audit events for all requests in RequestReceived stage.
    omitStages:
      - "RequestReceived"
    rules:
      # Log pod changes at RequestResponse level
      - level: RequestResponse
        resources:
        - group: ""
          # Resource "pods" doesn't match requests to any subresource of pods,
          # which is consistent with the RBAC policy.
          resources: ["pods"]
      # Log "pods/log", "pods/status" at Metadata level
      - level: Metadata
        resources:
        - group: ""
          resources: ["pods/log", "pods/status"]
    
      # Don't log requests to a configmap called "controller-leader"
      - level: None
        resources:
        - group: ""
          resources: ["configmaps"]
          resourceNames: ["controller-leader"]
    
      # Don't log watch requests by the "system:kube-proxy" on endpoints or services
      - level: None
        users: ["system:kube-proxy"]
        verbs: ["watch"]
        resources:
        - group: "" # core API group
          resources: ["endpoints", "services"]
    
      # Don't log authenticated requests to certain non-resource URL paths.
      - level: None
        userGroups: ["system:authenticated"]
        nonResourceURLs:
        - "/api*" # Wildcard matching.
        - "/version"
    
      # Log the request body of configmap changes in kube-system.
      - level: Request
        resources:
        - group: "" # core API group
          resources: ["configmaps"]
        # This rule only applies to resources in the "kube-system" namespace.
        # The empty string "" can be used to select non-namespaced resources.
        namespaces: ["kube-system"]
    
      # Log configmap and secret changes in all other namespaces at the Metadata level.
      - level: Metadata
        resources:
        - group: "" # core API group
          resources: ["secrets", "configmaps"]
    
      # Log all other resources in core and extensions at the Request level.
      - level: Request
        resources:
        - group: "" # core API group
        - group: "extensions" # Version of group should NOT be included.
    
      # A catch-all rule to log all other requests at the Metadata level.
      - level: Metadata
        # Long-running requests like watches that fall under this rule will not
        # generate an audit event in RequestReceived.
        omitStages:
          - "RequestReceived"

也可以使用最低限度的审计策略文件在 Metadata 级别记录所有请求：

# Log all requests at the Metadata level.
    apiVersion: audit.k8s.io/v1beta1
    kind: Policy
    rules:
    - level: Metadata

## 审计日志后端 ##

k8s目前提供两种日志后端，Log后端和webhook后端，Log后端可以将日志输出到文件，webhook后端将日志发送到远端日志服务器，接下来暂且只对Log后端日志的记录配置和采集做一下实践。

**以下实践组件版本docker ce17，k8s 1.9.2**

可以使用以下 kube-apiserver 标志配置 Log 审计后端：

**–audit-log-path**指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。- 意味着标准化

**–audit-log-maxage**定义了保留旧审计日志文件的最大天数

**–audit-log-maxbackup**定义了要保留的审计日志文件的最大数量

**–audit-log-maxsize**定义审计日志文件的最大大小（兆字节）

我司目前集群中kube-apiserver组件作为static pod方式运行，生命周期由kubelet直接管理，static pod由kebelet根据yaml文件创建，yaml存放路径为/etc/kubernetes/manifests/目录，其中apiserver由kubelet根据kube-apiserver.yaml创建，Log后端需要在kube-apiserver.yaml的启动参数里加以下参数：

--feature-gates=AdvancedAuditing=true
    --audit-policy-file=/etc/kubernetes/pki/audit-policy.yaml
    --audit-log-format=json
    --audit-log-path=/var/log/kubernetes/kubernetes-audit
    --audit-log-maxage=30 
    --audit-log-maxbackup=3 
    --audit-log-maxsize=100

**说明：**

*  AdvancedAuditing指明启用高级审计功能，即：可以使–audit-policy-file参数指定审计策略，该参数从k8s 1.8版本以后默认为true；
 *  audit-policy-file指定策略文件的位置，该路径为kube-apiserver容器内的路径，所以得从宿主机挂载策略文件到容器内，故暂且放在/etc/kubernetes/pki/目录下；
 *  audit-log-format指定最终审计日志的格式为json，该参数默认为json；
 *  audit-log-path指定最终审计日志存放在容器内的位置，该位置会自动创建。上述表示最终的审计日志文件为kubernetes-audit

**最终配置如下：**

![image][]

修改完成后，kubelet会自动删除重建kube-apiserver的pod（如果pod被删除后，过几分钟还不被创建，可以修改–audit-log-maxbackup的值保存退出，等待pod被创建—这可能是一个bug），重启状态变为running后可以进入容器查看生成的审计日志文件：

![image][image 1]

查看该日志：

![image][image 2]

达到100M后：

![image][image 3]

因为后面要用fluentd作为agent去采集该日志，所以需要把容器内的日志挂载到宿主机目录下，修改kube-apiserver.yaml如下，即将容器内/var/log/kubernetes目录挂载到宿主机的/var/log/kubernetes目录。

![image][image 4]

#### **日志采集** ####

目前集群中已部署了fluentd elasticsearch日志方案，所以选用fluentd作为 Logging-agent ，Elasticsearch作为 Logging Backend 。集群中的fluentd-es作为DaemonSet 方式运行，根据DaemonSet的特性，应该在每个Node上都会运行fluentd-es的pod，但实际情况是19环境上3个master节点都没有该pod。查看名为fluentd-es-v1.22的DaemonSet yaml可以发现，pod只会运行在有alpha.kubernetes.io/fluentd-ds-ready: “true”标签的node上：

![image][image 5]

查看master节点的node yaml，发现确实没有该标签。故需要在master节点node上添加该标签：

![image][image 6]

添加完label后，可以看到在docker-vm-6节点上pod会被自动创建。

Fluentd的配置文件在容器内的/etc/td-agent/td-agent.conf中配置，部分配置截图如下：

![image][image 7]

该配置由名为fluentd的ConfigMap指定：

![image][image 8]

可以看到配置里并不会去采集、转发审计日志/var/log/kubernetes/kubernetes-audit，所以需要在该ConfigMap中添加以下配置：

![image][image 9]

添加后的截图如下：

![image][image 10]

之后需要重启一下kube-apiserver节点的fluentd pod，fluentd采集时，也会输出日志到宿主机的/var/log/fluentd.log里，可以看到错误日志等信息，用于定位问题。如果该文件没有审计日志相关错误，日志应该就会被发送到logging-backend：elasticsearch，可以用以下命令验证：

*  先查看elasticsearch的service IP和Port，然后用curl命令调用rest接口查询当前集群中所有index信息：

![image][image 11]

*  查询到审计日志信息如下，大概有220万条记录：

![image][image 12]

详细信息如下，和审计日志文件中记录的一样：

![image][image 13]

后续可以用Kibana进行日志展示，Elasticsearch、Fluentd、Kibana即为大名鼎鼎的EFK日志收集方案，还有ELK等，可以根据项目的需求选择适当的组件。

--------------------

# 作者简洁 #

> 作者：小碗汤，一位热爱、认真写作的小伙，目前维护原创公众号：『我的小碗汤』，专注于写golang、docker、kubernetes等知识等提升硬实力的文章，期待你的关注。 转载说明：务必注明来源（注明：来源于公众号：我的小碗汤， 作者：小碗汤）

[image]: /images/20230531/9aa97f7c9a2048b0ab3c3bb599a5427a.png
[image 1]: /images/20230531/8eb84ecb2cd34bf1afbbb7ee6be6e429.png
[image 2]: /images/20230531/4ff52e04f16d4630a62450f865cdb970.png
[image 3]: /images/20230531/e8404488a1064cb3afd6becd650d9733.png
[image 4]: /images/20230531/a9ffa9ead2224b57a48026a1e6f56459.png
[image 5]: /images/20230531/44846e91f65b4ac79d95521cf97d751d.png
[image 6]: /images/20230531/97f8ec96139742fe993f4e92d1fdedfb.png
[image 7]: /images/20230531/816d85e8179844e7b1a2635b8002aaca.png
[image 8]: /images/20230531/45c49c9fda064c658ab9a74398248bea.png
[image 9]: /images/20230531/abc90a17b9824946879b562c00ea3297.png
[image 10]: /images/20230531/c720ae92848f44c6b84d5a8256012ef0.png
[image 11]: /images/20230531/eca069bccfb54e0d9e9c46577d532564.png
[image 12]: /images/20230531/8332b7e8d1ec40c78660219123e6b1d5.png
[image 13]: /images/20230531/838b041582e442c7bc90802dfa3986d5.png