Merge pull request #38806 from windsonsea/audity
[zh] sync /debug/debug-cluster/audit.md
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
a8801ad055
|
|
@ -10,9 +10,8 @@ reviewers:
|
|||
content_type: concept
|
||||
title: Auditing
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Kubernetes _auditing_ provides a security-relevant, chronological set of records documenting
|
||||
|
|
@ -82,6 +81,7 @@ Each request can be recorded with an associated _stage_. The defined stages are:
|
|||
- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
|
||||
- `Panic` - 当 panic 发生时生成。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The configuration of an
|
||||
[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
|
|
@ -89,7 +89,6 @@ is different from the
|
|||
[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
|
||||
API object.
|
||||
-->
|
||||
{{< note >}}
|
||||
[审计事件配置](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
的配置与 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
|
||||
API 对象不同。
|
||||
|
|
@ -194,7 +193,6 @@ Out of the box, the kube-apiserver provides two backends:
|
|||
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` 默认提供两个后端：
|
||||
|
|
@ -206,16 +204,16 @@ In all cases, audit events follow a structure defined by the Kubernetes API in t
|
|||
[`audit.k8s.io` API 组](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
|
||||
中定义的结构。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
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`.
|
||||
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`。
|
||||
`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`：
|
||||
|
||||
```json
|
||||
[
|
||||
|
|
@ -237,9 +235,6 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
|
|||
|
||||
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-backend}
|
||||
|
||||
|
|
@ -256,7 +251,7 @@ Log 后端将审计事件写入 [JSONlines](https://jsonlines.org/) 格式的
|
|||
- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化
|
||||
- `--audit-log-maxage` 定义保留旧审计日志文件的最大天数
|
||||
- `--audit-log-maxbackup` 定义要保留的审计日志文件的最大数量
|
||||
- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节）
|
||||
- `--audit-log-maxsize` 定义审计日志文件轮转之前的最大大小（兆字节）
|
||||
|
||||
<!--
|
||||
If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath`
|
||||
|
|
@ -270,6 +265,9 @@ to the location of the policy file and log file, so that audit records are persi
|
|||
--audit-log-path=/var/log/kubernetes/audit/audit.log
|
||||
```
|
||||
|
||||
<!--
|
||||
then mount the volumes:
|
||||
-->
|
||||
接下来挂载数据卷：
|
||||
|
||||
```yaml
|
||||
|
|
@ -347,7 +345,7 @@ throttling is enabled in `webhook` and disabled in `log`.
|
|||
同样，默认情况下，在 `webhook` 中启用带宽限制，在 `log` 中禁用带宽限制。
|
||||
|
||||
<!--
|
||||
- `--audit-webhook-mode` defines the buffering strategy. One of the following:
|
||||
- `--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
|
||||
|
|
@ -356,8 +354,8 @@ throttling is enabled in `webhook` and disabled in `log`.
|
|||
- `--audit-webhook-mode` 定义缓存策略，可选值如下：
|
||||
- `batch` - 以批处理缓存事件和异步的过程。这是默认值。
|
||||
- `blocking` - 在 API 服务器处理每个单独事件时，阻塞其响应。
|
||||
- `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived 阶段
|
||||
失败时，整个 API 服务请求会失效。
|
||||
- `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived
|
||||
阶段失败时，整个 API 服务请求会失效。
|
||||
|
||||
<!--
|
||||
The following flags are used only in the `batch` mode:
|
||||
|
|
@ -426,7 +424,7 @@ As an example, the following is the list of flags available for the log backend:
|
|||
-->
|
||||
### 日志条目截断 {#truncate}
|
||||
|
||||
日志后端和 Webhook 后端都支持限制所输出的事件的尺寸。
|
||||
日志后端和 Webhook 后端都支持限制所输出的事件大小。
|
||||
例如，下面是可以为日志后端配置的标志列表：
|
||||
|
||||
<!--
|
||||
|
|
@ -435,8 +433,8 @@ As an example, the following is the list of flags available for the log 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`：向下层后端发送的审计事件的最大尺寸字节数。
|
||||
- `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
|
||||
|
|
|
|||
Loading…
Reference in New Issue