kubernetes审计日志auditing

一、什么是审计

            Kubernetes 审计（Auditing） 功能提供了与安全相关的、按时间顺序排列的记录集， 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动

         审计功能解决如下问题：       

• 发生了什么？
• 什么时候发生的？
• 谁触发的？
• 活动发生在哪个（些）对象上？
• 在哪观察到的？
• 它从哪触发的？
• 活动的后续处理行为是什么？

二、kubernetes审计基础概念

        2.1 阶段stage

                每个对API的请求，在不同的执行阶段会生成审计事件，审计事件根据特定的策略处理并写入后端

                已定义如下阶段：            

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

        2.2 审计策略

                审计策略定义了关于应记录哪些事件以及应包含哪些数据的规则

                已定义的审计级别有：   

• None - 符合这条规则的日志将不会记录。
• Metadata - 记录请求的元数据（请求的用户、时间戳、资源、动词等等）， 但是不记录请求或者响应的消息体。
• Request - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。 这不适用于非资源类型的请求。
• RequestResponse - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求

            官网审计策略样板：

apiVersion: audit.k8s.io/v1 # 这是必填项。
kind: Policy
# 不要在 RequestReceived 阶段为任何请求生成审计事件。
omitStages:
  - "RequestReceived"
rules:
  # 在日志中用 RequestResponse 级别记录 Pod 变化。
  - level: RequestResponse
    resources:
    - group: ""
      # 资源 "pods" 不匹配对任何 Pod 子资源的请求，
      # 这与 RBAC 策略一致。
      resources: ["pods"]
  # 在日志中按 Metadata 级别记录 "pods/log"、"pods/status" 请求
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # 不要在日志中记录对名为 "controller-leader" 的 configmap 的请求。
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # 不要在日志中记录由 "system:kube-proxy" 发出的对端点或服务的监测请求。
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API 组
      resources: ["endpoints", "services"]

  # 不要在日志中记录对某些非资源 URL 路径的已认证请求。
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # 通配符匹配。
    - "/version"

  # 在日志中记录 kube-system 中 configmap 变更的请求消息体。
  - level: Request
    resources:
    - group: "" # core API 组
      resources: ["configmaps"]
    # 这个规则仅适用于 "kube-system" 名字空间中的资源。
    # 空字符串 "" 可用于选择非名字空间作用域的资源。
    namespaces: ["kube-system"]

  # 在日志中用 Metadata 级别记录所有其他名字空间中的 configmap 和 secret 变更。
  - level: Metadata
    resources:
    - group: "" # core API 组
      resources: ["secrets", "configmaps"]

  # 在日志中以 Request 级别记录所有其他 core 和 extensions 组中的资源操作。
  - level: Request
    resources:
    - group: "" # core API 组
    - group: "extensions" # 不应包括在内的组版本。

  # 一个抓取所有的规则，将在日志中以 Metadata 级别记录所有其他请求。
  - level: Metadata
    # 符合此规则的 watch 等长时间运行的请求将不会
    # 在 RequestReceived 阶段生成审计事件。
    omitStages:
      - "RequestReceived"
 

        2.3 审计后端

                审计后端实现将审计事件导出到外部存储。kube-apiserver 默认提供两个后端：

• Log 后端，将事件写入到文件系统
• Webhook 后端，将事件发送到外部 HTTP API

         Log后端配置参数：

• --audit-log-path 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。- 意味着标准化
• --audit-log-maxage 定义保留旧审计日志文件的最大天数
• --audit-log-maxbackup 定义要保留的审计日志文件的最大数量
• --audit-log-maxsize 定义审计日志文件轮转之前的最大大小（兆字节）

 注意：如果是kubeadm部署，kube-apiserver以Pod形式运行，需要通过挂载卷的形式：

volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false

volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File
 
- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

 Webhook 后端：

        Webhook 后端将审计事件发送到远程 Web AP

• --audit-webhook-config-file 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个 kubeconfig 文件。
• --audit-webhook-initial-backoff 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重

        

三、kubernetes添加审计功能

   3.1 添加策略文件

                参见2.2 审计策略配置模板

    3.2 kube-apiserver服务添加audit功能

  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/kube-audit \
  --audit-log-format=json \
  --audit-log-maxbackup=10 \
  --audit-log-maxsize=1000 

注意：我这里是二进制部署的kubernetes，直接修改kube-apiserver.service文件，重启kube-apiserver服务即可

   备注：详细资料，参见：审计 | Kubernetes