diff --git a/content/zh/docs/tasks/debug/debug-cluster/audit.md b/content/zh/docs/tasks/debug/debug-cluster/audit.md new file mode 100644 index 0000000000..b4b4c9ee66 --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-cluster/audit.md @@ -0,0 +1,453 @@ +--- +title: 审计 +content_type: concept +--- +<!-- +reviewers: +- soltysh +- sttts +- ericchiang +content_type: concept +title: Auditing +--> +<!-- overview --> + +{{< feature-state state="beta" >}} + +<!-- +Kubernetes _auditing_ provides a security-relevant, chronological set of records documenting +the sequence of actions in a cluster. The cluster audits the activities generated by users, +by applications that use the Kubernetes API, and by the control plane itself. + +Auditing allows cluster administrators to answer the following questions: +--> +Kubernetes _审计(Auditing)_ 功能提供了与安全相关的、按时间顺序排列的记录集, +记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。 + +审计功能使得集群管理员能够回答以下问题: + +<!-- + - what happened? + - when did it happen? + - who initiated it? + - on what did it happen? + - where was it observed? + - from where was it initiated? + - to where was it going? +--> + - 发生了什么? + - 什么时候发生的? + - 谁触发的? + - 活动发生在哪个(些)对象上? + - 在哪观察到的? + - 它从哪触发的? + - 活动的后续处理行为是什么? + +<!-- body --> + +<!-- +Audit records begin their lifecycle inside the +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +component. Each request on each stage +of its execution generates an audit event, which is then pre-processed according to +a certain policy and written to a backend. The policy determines what's recorded +and the backends persist the records. The current backend implementations +include logs files and webhooks. +--> +审计记录最初产生于 +[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +内部。每个请求在不同执行阶段都会生成审计事件;这些审计事件会根据特定策略 +被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。 +当前的后端支持日志文件和 webhook。 + +<!-- +Each request can be recorded with an associated _stage_. The defined stages are: + +- `RequestReceived` - The stage for events generated as soon as the audit + handler receives the request, and before it is delegated down the handler + chain. +- `ResponseStarted` - Once the response headers are sent, but before the + response body is sent. This stage is only generated for long-running requests + (e.g. watch). +- `ResponseComplete` - The response body has been completed and no more bytes + will be sent. +- `Panic` - Events generated when a panic occurred. +--> +每个请求都可被记录其相关的 _阶段(stage)_。已定义的阶段有: + +- `RequestReceived` - 此阶段对应审计处理器接收到请求后,并且在委托给 + 其余处理器之前生成的事件。 +- `ResponseStarted` - 在响应消息的头部发送后,响应消息体发送前生成的事件。 + 只有长时间运行的请求(例如 watch)才会生成这个阶段。 +- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。 +- `Panic` - 当 panic 发生时生成。 + +<!-- +The configuration of an +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +is different from the +[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) +API object. +--> +{{< note >}} +[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +的配置与 [Event](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) +API 对象不同。 +{{< /note >}} + +<!-- +The audit logging feature increases the memory consumption of the API server +because some context required for auditing is stored for each request. +Additionally, memory consumption depends on the audit logging configuration. +--> +审计日志记录功能会增加 API server 的内存消耗,因为需要为每个请求存储审计所需的某些上下文。 +此外,内存消耗取决于审计日志记录的配置。 + +<!-- +## Audit Policy + +Audit policy defines rules about what events should be recorded and what data +they should include. The audit policy object structure is defined in the +[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy). +When an event is processed, it's +compared against the list of rules in order. The first matching rule sets the +_audit level_ of the event. The defined audit levels are: +--> +## 审计策略 {#audit-policy} + +审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。 +审计策略对象结构定义在 +[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +处理事件时,将按顺序与规则列表进行比较。第一个匹配规则设置事件的 +_审计级别(Audit Level)_。已定义的审计级别有: + +<!-- +- `None` - don't log events that match this rule. +- `Metadata` - log request metadata (requesting user, timestamp, resource, + verb, etc.) but not request or response body. +- `Request` - log event metadata and request body but not response body. + This does not apply for non-resource requests. +- `RequestResponse` - log event metadata, request and response bodies. + This does not apply for non-resource requests. +--> +- `None` - 符合这条规则的日志将不会记录。 +- `Metadata` - 记录请求的元数据(请求的用户、时间戳、资源、动词等等), + 但是不记录请求或者响应的消息体。 +- `Request` - 记录事件的元数据和请求的消息体,但是不记录响应的消息体。 + 这不适用于非资源类型的请求。 +- `RequestResponse` - 记录事件的元数据,请求和响应的消息体。这不适用于非资源类型的请求。 + +<!-- +You can pass a file with the policy to `kube-apiserver` +using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. +Note that the `rules` field __must__ be provided in the audit policy file. +A policy with no (0) rules is treated as illegal. + +Below is an example audit policy file: +--> +你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。 +如果不设置该标志,则不记录事件。 +注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有(0)规则的策略将被视为非法配置。 + +以下是一个审计策略文件的示例: + +{{< codenew file="audit/audit-policy.yaml" >}} + +<!-- +You can use a minimal audit policy file to log all requests at the `Metadata` level: +--> +你可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求: + +```yaml +# 在 Metadata 级别为所有请求生成日志 +apiVersion: audit.k8s.io/v1beta1 +kind: Policy +rules: +- level: Metadata +``` + +<!-- +If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) +script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script. + +You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +for details about the fields defined. +--> +如果你在打磨自己的审计配置文件,你可以使用为 Google Container-Optimized OS +设计的审计配置作为出发点。你可以参考 +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) +脚本,该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。 + +你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +以获取有关已定义字段的详细信息。 + +<!-- +## Audit backends + +Audit backends persist audit events to an external storage. +Out of the box, the kube-apiserver provides two backends: + +- Log backend, which writes events into the filesystem +- Webhook backend, which sends events to an external HTTP API + +In all cases, audit events follow a structure defined by the Kubernetes API in the +[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event). +--> + +## 审计后端 {#audit-backends} + +审计后端实现将审计事件导出到外部存储。`Kube-apiserver` 默认提供两个后端: + +- Log 后端,将事件写入到文件系统 +- Webhook 后端,将事件发送到外部 HTTP API + +在这所有情况下,审计事件均遵循 Kubernetes API 在 +[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +中定义的结构。 + +<!-- +In case of patches, request body is a JSON array with patch operations, not a JSON object +with an appropriate Kubernetes API object. For example, the following request body is a valid patch +request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`. +--> +{{< note >}} +对于 patch 请求,请求的消息体需要是设定 patch 操作的 JSON 所构成的一个串, +而不是一个完整的 Kubernetes API 对象 JSON 串。 +例如,以下的示例是一个合法的 patch 请求消息体,该请求对应 +`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。 + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` +{{< /note >}} + +<!-- +### Log backend + +The log backend writes audit events to a file in [JSONlines](https://jsonlines.org/) format. +You can configure the log audit backend using the following `kube-apiserver` flags: + +Log backend writes audit events to a file in JSON format. You can configure +log audit backend using the following [kube-apiserver][kube-apiserver] flags: +--> +### Log 后端 + +Log 后端将审计事件写入 [JSONlines](https://jsonlines.org/) 格式的文件。 +你可以使用以下 `kube-apiserver` 标志配置 Log 审计后端: + +<!-- +- `--audit-log-path` specifies the log file path that log backend uses to write + audit events. Not specifying this flag disables log backend. `-` means standard out +- `--audit-log-maxage` defined the maximum number of days to retain old audit log files +- `--audit-log-maxbackup` defines the maximum number of audit log files to retain +- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated +--> +- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化 +- `--audit-log-maxage` 定义保留旧审计日志文件的最大天数 +- `--audit-log-maxbackup` 定义要保留的审计日志文件的最大数量 +- `--audit-log-maxsize` 定义审计日志文件的最大大小(兆字节) + +<!-- +If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath` +to the location of the policy file and log file, so that audit records are persisted. For example: +--> +如果你的集群控制面以 Pod 的形式运行 kube-apiserver,记得要通过 `hostPath` +卷来访问策略文件和日志文件所在的目录,这样审计记录才会持久保存下来。例如: + +```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml + --audit-log-path=/var/log/kubernetes/audit/audit.log +``` + +接下来挂载数据卷: + +```yaml +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/kubernetes/audit/ + name: audit-log + readOnly: false +``` + +<!-- +and finally configure the `hostPath`: +--> +最后配置 `hostPath`: + +```yaml +... +volumes: +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/kubernetes/audit/ + type: DirectoryOrCreate +``` + +<!-- +### Webhook backend + +The webhook audit backend sends audit events to a remote web API, which is assumed to +be a form of the Kubernetes API, including means of authentication. You can configure +a webhook audit backend using the following kube-apiserver flags: +--> +### Webhook 后端 {#webhook-backend} + +Webhook 后端将审计事件发送到远程 Web API,该远程 API 应该暴露与 `kube-apiserver` +形式相同的 API,包括其身份认证机制。你可以使用如下 kube-apiserver 标志来配置 +Webhook 审计后端: + +<!-- +- `--audit-webhook-config-file` specifies the path to a file with a webhook + configuration. The webhook configuration is effectively a specialized + [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). +- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed + request before retrying. Subsequent requests are retried with exponential backoff. + +The webhook config file uses the kubeconfig format to specify the remote address of +the service and credentials used to connect to it. +--> +- `--audit-webhook-config-file` 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个 + [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。 +- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。 + +Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。 + +<!-- +## Event batching {#batching} + +Both log and webhook backends support batching. Using webhook as an example, here's the list of +available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag +name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default +throttling is enabled in `webhook` and disabled in `log`. +--> +## 事件批处理 {#batching} + +日志和 Webhook 后端都支持批处理。以 Webhook 为例,以下是可用参数列表。要获取日志 +后端的同样参数,请在参数名称中将 `webhook` 替换为 `log`。 +默认情况下,在 `webhook` 中批处理是被启用的,在 `log` 中批处理是被禁用的。 +同样,默认情况下,在 `webhook` 中启用带宽限制,在 `log` 中禁用带宽限制。 + +<!-- + - `--audit-webhook-mode` defines the buffering strategy. One of the following: + - `batch` - buffer events and asynchronously process them in batches. This is the default. + - `blocking` - block API server responses on processing each individual event. + - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at the + RequestReceived stage, the whole request to the kube-apiserver fails. +--> +- `--audit-webhook-mode` 定义缓存策略,可选值如下: + - `batch` - 以批处理缓存事件和异步的过程。这是默认值。 + - `blocking` - 在 API 服务器处理每个单独事件时,阻塞其响应。 + - `blocking-strict` - 与 `blocking` 相同,不过当审计日志在 RequestReceived 阶段 + 失败时,整个 API 服务请求会失效。 + +<!-- +The following flags are used only in the `batch` mode. + +- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching. + If the rate of incoming events overflows the buffer, events are dropped. +- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch. +- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally + batching events in the queue. +- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated + per second. +- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same + moment if the allowed QPS was underutilized previously. +--> +以下参数仅用于 `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 生成数。 + +<!-- +## Parameter tuning + +Parameters should be set to accommodate the load on the API server. + +For example, if kube-apiserver receives 100 requests each second, and each request is audited only +on `ResponseStarted` and `ResponseComplete` stages, you should account for ≅200 audit +events being generated each second. Assuming that there are up to 100 events in a batch, +you should set throttling level at least 2 queries per second. Assuming that the backend can take up to +5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events; +that is: 10 batches, or 1000 events. +--> +## 参数调整 {#parameter-tuning} + +需要设置参数以适应 API 服务器上的负载。 + +例如,如果 kube-apiserver 每秒收到 100 个请求,并且每个请求仅在 `ResponseStarted` +和 `ResponseComplete` 阶段进行审计,则应该考虑每秒生成约 200 个审计事件。 +假设批处理中最多有 100 个事件,则应将限制级别设置为每秒至少 2 个查询。 +假设后端最多需要 5 秒钟来写入事件,你应该设置缓冲区大小以容纳最多 5 秒的事件, +即 10 个 batch,即 1000 个事件。 + +<!-- +In most cases however, the default parameters should be sufficient and you don't have to worry about +setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver +and in the logs to monitor the state of the auditing subsystem. + +- `apiserver_audit_event_total` metric contains the total number of audit events exported. +- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error + during exporting. +--> +但是,在大多数情况下,默认参数应该足够了,你不必手动设置它们。 +你可以查看 kube-apiserver 公开的以下 Prometheus 指标,并在日志中监控审计子系统的状态。 + +- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。 +- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。 + +<!-- +### Log entry truncation {#truncate} + +Both log and webhook backends support limiting the size of events that are logged. +As an example, the following is the list of flags available for the log backend: +--> +### 日志条目截断 {#truncate} + +日志后端和 Webhook 后端都支持限制所输出的事件的尺寸。 +例如,下面是可以为日志后端配置的标志列表: + +<!-- +- `audit-log-truncate-enabled` whether event and batch truncating is enabled. +- `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend. +- `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend. +--> +- `audit-log-truncate-enabled`:是否弃用事件和批次的截断处理。 +- `audit-log-truncate-max-batch-size`:向下层后端发送的各批次的最大尺寸字节数。 +- `audit-log-truncate-max-event-size`:向下层后端发送的审计事件的最大尺寸字节数。 + +<!-- +By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set +`audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature. +--> +默认情况下,截断操作在 `webhook` 和 `log` 后端都是被禁用的,集群管理员需要设置 +`audit-log-truncate-enabled` 或 `audit-webhook-truncate-enabled` 标志来启用此操作。 + +## {{% heading "whatsnext" %}} + +<!-- +* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). +--> +* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。 +