审计

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

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

    审计记录最初产生于 内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略 被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。 当前的后端支持日志文件和 webhook。

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

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

    审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。 审计策略对象结构定义在 audit.k8s.io API 组 处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 “审计级别”。已知的审计级别有：

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

    你可以使用 --audit-policy-file 标志将包含策略的文件传递给 kube-apiserver。 如果不设置该标志，则不记录事件。 注意 rules 字段 必须 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。

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

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

    1. # 在 Metadata 级别为所有请求生成日志
    2. apiVersion: audit.k8s.io/v1beta1
    3. kind: Policy
    4. rules:
    5. - level: Metadata

    管理员构建自己的审计配置文件时，可参考 configure-helper.sh 脚本，该脚本生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。 []。

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

    • Log 后端，将事件写入到磁盘
    • Webhook 后端，将事件发送到外部 API

    在这两种情况下，审计事件结构均由 audit.k8s.io API 组中的 API 定义。 当前版本的 API 是 .

    Log 后端将审计事件写入 JSON 格式的文件。你可以使用以下 kube-apiserver 标志配置 Log 审计后端：

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

    如果 kube-apiserver 被配置为运行在 Pod 中，请记得将包含策略文件和日志文件的 位置用 hostPath 挂载到 Pod 中。例如，

    1. --audit-policy-file=/etc/kubernetes/audit-policy.yaml
    2. --audit-log-path=/var/log/audit.log

    接下来挂载数据卷：

    下面是 hostPath 卷本身。

    1. - name: audit
    2.   hostPath:
    3.     path: /etc/kubernetes/audit-policy.yaml
    4.     type: File
    6. - name: audit-log
    7.     path: /var/log/audit.log
    8.     type: FileOrCreate

    Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 kube-apiserver 相同的API。 你可以使用如下 kube-apiserver 标志来配置 webhook 审计后端：

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

    webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。

    log 和 webhook 后端都支持批处理。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数， 请在参数名称中将 webhook 替换为 。 默认情况下，在 webhook 中启用批处理，在 log 中禁用批处理。 同样，默认情况下，在 webhook 中启用带宽限制，在 log 中禁用带宽限制。

    • --audit-webhook-mode 定义缓存策略，可选值如下：
      • batch - 以批处理缓存事件和异步的过程。这是默认值。
      • blocking - 在 API 服务器处理每个单独事件时，阻塞其响应。
      • blocking-strict - 与 blocking 相同，不过当审计日志在 RequestReceived 阶段 失败时，整个 API 服务请求会失效。

    以下参数仅用于 batch 模式。

    • --audit-webhook-batch-buffer-size 定义 batch 之前要缓存的事件数。 如果传入事件的速率溢出缓存区，则会丢弃事件。
    • --audit-webhook-batch-max-size 定义一个 batch 中的最大事件数。
    • --audit-webhook-batch-max-wait 无条件 batch 队列中的事件前等待的最大事件。
    • --audit-webhook-batch-throttle-qps 每秒生成的最大批次数。
    • --audit-webhook-batch-throttle-burst 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。

    参数调整

    需要设置参数以适应 apiserver 上的负载。

    例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 ResponseStarted 和 ResponseComplete 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。 假设批处理中最多有 100 个事件，则应将限制级别设置为至少 2 个 QPS。 假设后端最多需要 5 秒钟来写入事件，你应该设置缓冲区大小以容纳最多 5 秒的事件，即 10 个 batch，即 1000 个事件。

    但是，在大多数情况下，默认参数应该足够了，你不必手动设置它们。 你可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。

    • apiserver_audit_event_total 包含所有暴露的审计事件数量的指标。
    • apiserver_audit_error_total 在暴露时由于发生错误而被丢弃的事件的数量。

    如果你通过 对 Kubernetes API 进行扩展，那么你也可以为聚合的 API 服务器设置审计日志。 想要这么做，你需要以上述的格式给聚合的 API 服务器配置参数，并且配置日志管道以采用审计日志。 不同的 API 服务器可以配置不同的审计配置和策略。

    Fluentd 是一个开源的数据采集器，可以从统一的日志层中采集。 在以下示例中，我们将使用 fluentd 来按照命名空间划分审计事件。

    1. 在 kube-apiserver 节点上安装 、 , fluent-plugin-forest 和 fluent-plugin-rewrite-tag-filter。

    2. 为 fluentd 创建一个配置文件

      1. $ cat <<EOF > /etc/fluentd/config
      2. # fluentd 运行在 kube-apiserver 相同的主机上
      3. <source>
      4.      @type tail
      5.      # kube-apiserver 审计日志路径
      6.      path /var/log/audit
      7.      pos_file /var/log/audit.pos
      8.      format json
      9.      time_key time
      10.      time_format %Y-%m-%dT%H:%M:%S.%N%z
      11.      tag audit
      12. </source>
      14. <filter audit>
      15.      #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
      16.      type record_transformer
      17.      enable_ruby
      18.      <record>
      19.       namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ?  "none":record["objectRef"]["namespace"])}
      20.      </record>
      21. </filter>
      23. <match audit>
      24.      # 根据上下文中的名字空间元素对审计进行路由
      25.      @type rewrite_tag_filter
      26.      rewriterule1 namespace ^(.+) ${tag}.$1
      27. </match>
      29. <filter audit.**>
      30.     @type record_transformer
      31.     remove_keys namespace
      32. </filter>
      35.      @type forest
      36.      subtype file
      37.      remove_prefix audit
      38.      <template>
      39.          time_slice_format %Y%m%d%H
      40.          path /var/log/audit-${tag}.*.log
      41.          format json
      42.          include_time_key true
      43.      </template>
      44. </match>

    3. 启动 fluentd

      1. fluentd -c /etc/fluentd/config  -vv

    4. 给 kube-apiserver 配置以下参数并启动：

    5. 在 /var/log/audit-*.log 文件中检查不同命名空间的审计事件

    Logstash 是一个开源的、服务器端的数据处理工具。 在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。

    1. 安装

    2. 为 logstash 创建配置文件

      1. cat <<EOF > /etc/logstash/config
      2. input{
      3.     http{
      4.         #TODO, figure out a way to use kubeconfig file to authenticate to logstash
      5.         #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
      6.         port=>8888
      7.     }
      8. }
      9. filter{
      10.     split{
      11.         # Webhook 审计后端与 EventList 一起发送若干事件
      12.         # 对事件进行分割
      13.         field=>[items]
      14.         # 我们只需要 event 子元素，去掉其他元素
      15.         remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
      16.     }
      17.     mutate{
      18.         rename => {items=>event}
      19.     }
      20. }
      21. output{
      22.     file{
      23.         # 来自不同用户的审计事件会被保存到不同文件中
      24.         path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
      25.     }
      26. }

    3. 启动 logstash

      1. bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/

    4. 为 kube-apiserver webhook 审计后端创建一个 kubeconfig 文件：

    1. cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
    2. apiVersion: v1
    3. clusters:
    4. - cluster:
    5.     server: http://<ip_of_logstash>:8888
    6.   name: logstash
    7. contexts:
    8. - context:
    9.     cluster: logstash
    10.     user: ""
    11.   name: default-context
    12. current-context: default-context
    13. kind: Config
    14. preferences: {}
    15. users: []
    16. EOF

    1. 在 logstash 节点的 /var/log/kube-audit-*/audit 目录中检查审计事件

    请注意，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。 例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。