审计

Kubernetes _审计_ 提供了安全相关的、按时间顺序排列的记录集，记录了集群中操作的顺序。集群会审计用户、使用 Kubernetes API 的应用程序以及控制平面本身生成的活动。

审计允许集群管理员回答以下问题

发生了什么？
什么时候发生的？
谁发起的？
它发生在什么上面？
在哪里观察到的？
从哪里发起的？
它将去往哪里？

审计记录的生命周期从 kube-apiserver 组件内部开始。执行过程中的每个阶段的每个请求都会生成一个审计事件，然后根据特定策略对其进行预处理并写入后端。该策略决定了记录的内容，后端会持久化这些记录。当前的后端实现包括日志文件和 webhooks。

每个请求都可以与关联的 _阶段_ 一起记录。定义的阶段是

RequestReceived - 审计处理程序收到请求后，并在将其向下委托到处理程序链之前生成的事件的阶段。
ResponseStarted - 一旦响应头已发送，但在响应主体发送之前。此阶段仅针对长时间运行的请求（例如 watch）生成。
ResponseComplete - 响应主体已完成，不再发送任何字节。
Panic - 发生恐慌时生成的事件。

注意

审计事件配置的配置与事件 API 对象不同。

审计日志记录功能会增加 API 服务器的内存消耗，因为每个请求都需要存储一些用于审计的上下文。内存消耗取决于审计日志记录配置。

审计策略

审计策略定义了有关应记录哪些事件以及它们应包含哪些数据的规则。审计策略对象结构在 audit.k8s.io API 组中定义。当处理事件时，会将其与规则列表进行比较。第一个匹配的规则会设置事件的 _审计级别_。定义的审计级别是

None - 不要记录与该规则匹配的事件。
Metadata - 记录请求元数据（请求用户、时间戳、资源、动词等），但不记录请求或响应主体。
Request - 记录事件元数据和请求主体，但不记录响应主体。这并不适用于非资源请求。
RequestResponse - 记录事件元数据、请求和响应主体。这并不适用于非资源请求。

您可以使用带有策略的文件，通过 --audit-policy-file 标志传递给 kube-apiserver。如果省略了该标志，则不会记录任何事件。请注意，rules 字段 **必须** 在审计策略文件中提供。没有（0 个）规则的策略将被视为非法。

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

audit/audit-policy.yaml

apiVersion: audit.k8s.io/v1 # 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/v1
kind: Policy
rules:
- level: Metadata

如果您正在创建自己的审计配置文件，您可以使用 Google Container-Optimized OS 的审计配置文件作为起点。您可以查看 configure-helper.sh 脚本，它会生成一个审计策略文件。您可以通过直接查看该脚本来查看大部分审计策略文件。

您还可以参考 Policy 配置参考以了解定义的字段的详细信息。

审计后端

审计后端将审计事件持久化到外部存储。开箱即用，kube-apiserver 提供了两个后端

日志后端，它将事件写入文件系统
Webhook 后端，它将事件发送到外部 HTTP API

在所有情况下，审计事件都遵循 Kubernetes API 在 audit.k8s.io API 组中定义的结构。

注意

在补丁的情况下，请求主体是一个包含补丁操作的 JSON 数组，而不是包含适当 Kubernetes API 对象的 JSON 对象。例如，以下请求主体是针对 /apis/batch/v1/namespaces/some-namespace/jobs/some-job-name 的有效补丁请求

[
  {
    "op": "replace",
    "path": "/spec/parallelism",
    "value": 0
  },
  {
    "op": "remove",
    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
  }
]

日志后端

日志后端将审计事件写入 JSONlines 格式的文件中。您可以使用以下 kube-apiserver 标志配置日志审计后端

--audit-log-path 指定日志后端用于写入审计事件的日志文件路径。不指定此标志将禁用日志后端。- 表示标准输出
--audit-log-maxage 定义保留旧审计日志文件的最大天数
--audit-log-maxbackup 定义要保留的审计日志文件的最大数量
--audit-log-maxsize 定义审计日志文件在旋转之前可以达到的最大大小（以兆字节为单位）

如果您的集群的控制平面将 kube-apiserver 作为 Pod 运行，请记住将 hostPath 装载到策略文件和日志文件的位置，以便持久化审计记录。例如

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

然后装载卷

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

最后配置 hostPath

...
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 API，该 API 被假定为 Kubernetes API 的一种形式，包括身份验证方式。您可以使用以下 kube-apiserver 标志配置 Webhook 审计后端

--audit-webhook-config-file 指定包含 Webhook 配置的文件的路径。Webhook 配置实际上是一个专门的 kubeconfig。
--audit-webhook-initial-backoff 指定在第一次失败请求后等待的时间量，然后再重试。后续请求将以指数级退避的方式重试。

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

事件批处理

日志和 Webhook 后端都支持批处理。以 Webhook 为例，以下是可用标志的列表。要获取日志后端相同的标志，请将标志名称中的 webhook 替换为 log。默认情况下，批处理在 webhook 中启用，而在 log 中禁用。类似地，默认情况下，节流在 webhook 中启用，而在 log 中禁用。

--audit-webhook-mode 定义缓冲策略。以下选项之一
- batch - 缓冲事件并异步地以批次处理它们。这是默认设置。
- blocking - 在处理每个单独的事件时阻塞 API 服务器响应。
- blocking-strict - 与阻塞相同，但在 RequestReceived 阶段审计日志记录失败时，整个 kube-apiserver 请求也会失败。

以下标志仅在 batch 模式下使用

--audit-webhook-batch-buffer-size 定义在批处理之前要缓冲的事件数量。如果传入事件的速率超过缓冲区，则会丢弃事件。
--audit-webhook-batch-max-size 定义单个批次中的最大事件数量。
--audit-webhook-batch-max-wait 定义在无条件地对队列中的事件进行批处理之前要等待的最大时间量。
--audit-webhook-batch-throttle-qps 定义每秒生成的批次的平均最大数量。
--audit-webhook-batch-throttle-burst 定义如果之前未充分利用允许的 QPS，则在同一时刻生成的批次的最大数量。

参数调整

应设置参数以适应 API 服务器上的负载。

例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 ResponseStarted 和 ResponseComplete 阶段进行审计，则应考虑每秒生成 ≅200 个审计事件。假设一个批次最多有 100 个事件，则应将节流级别设置为至少每秒 2 个查询。假设后端最多需要 5 秒才能写入事件，则应将缓冲区大小设置为容纳最多 5 秒的事件；也就是：10 个批次，或 1000 个事件。

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

apiserver_audit_event_total 指标包含已导出的审计事件的总数。
apiserver_audit_error_total 指标包含由于导出过程中的错误而导致的已丢弃事件的总数。

日志条目截断

日志和 Webhook 后端都支持限制记录的事件的大小。例如，以下是日志后端可用的标志列表

audit-log-truncate-enabled 是否启用事件和批处理截断。
audit-log-truncate-max-batch-size 发送到底层后端的批次的字节最大大小。
audit-log-truncate-max-event-size 发送到底层后端的审计事件的字节最大大小。

默认情况下，截断在 webhook 和 log 中都禁用，集群管理员应设置 audit-log-truncate-enabled 或 audit-webhook-truncate-enabled 以启用此功能。

下一步

了解变异 Webhook 审计注释。
通过阅读审计配置参考，了解有关 Event 和 Policy 资源类型的更多信息。

上次修改时间：2023 年 8 月 24 日下午 6:38 PST：使用 code_sample 短代码代替 code 短代码 (e8b136c3b3)