后浪云kubernetes教程：Kubernetes 审计

发布时间:2025-04-05 12:30:42

阅读量:295

审计

FEATURESTATE:Kubernetesv1.24[beta]

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

审计功能使得集群管理员能够回答以下问题：

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

每个请求都可被记录其相关的阶段（stage）。已定义的阶段有：

Note:审计事件配置的配置与EventAPI对象不同。

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

审计策略

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

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

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

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级别记录所有请求：

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

如果你在打磨自己的审计配置文件，你可以使用为GoogleContainer-OptimizedOS设计的审计配置作为出发点。你可以参考configure-helper.sh脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。

你也可以参考Policy配置参考以获取有关已定义字段的详细信息。

审计后端

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

在这所有情况下，审计事件均遵循KubernetesAPI在audit.k8s.ioAPI组中定义的结构。

Note:

对于patch请求，请求的消息体需要是设定patch操作的JSON所构成的一个串，而不是一个完整的KubernetesAPI对象JSON串。例如，以下的示例是一个合法的patch请求消息体，该请求对应

/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"
  }
]

Log后端

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

如果你的集群控制面以Pod的形式运行kube-apiserver，记得要通过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后端将审计事件发送到远程WebAPI，该远程API应该暴露与kube-apiserver形式相同的API，包括其身份认证机制。你可以使用如下kube-apiserver标志来配置Webhook审计后端：

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

事件批处理

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

以下参数仅用于batch模式。

参数调整

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

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

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

日志条目截断

日志后端和Webhook后端都支持限制所输出的事件的尺寸。例如，下面是可以为日志后端配置的标志列表：

默认情况下，截断操作在webhook和log后端都是被禁用的，集群管理员需要设置audit-log-truncate-enabled或audit-webhook-truncate-enabled标志来启用此操作。