Merge pull request #53358 from my-git9/npe-4169

[zh-cn]sync authorization validating-admission-policy mutating-admission-policy

Author: k8s-ci-robot

content/zh-cn/docs/reference/access-authn-authz/authorization.md

@@ -265,8 +265,9 @@ Kubernetes 需要 REST API 请求所共有的属性，
   要了解有关 Node 鉴权模式的更多信息，请参阅 [Node 鉴权](/zh-cn/docs/reference/access-authn-authz/node/)。
 
 `Webhook`
-: Kubernetes 的 [Webhook 鉴权模式](/docs/reference/access-authn-authz/webhook/)用于鉴权，进行同步 HTTP 调用，
-  阻塞请求直到远程 HTTP 服务响应查询。你可以编写自己的软件来处理这种向外调用，也可以使用生态系统中的解决方案。
+: Kubernetes 的 [Webhook 鉴权模式](/docs/reference/access-authn-authz/webhook/)用于鉴权，
+  进行同步 HTTP 调用，阻塞请求直到远程 HTTP 服务响应查询。
+  你可以编写自己的软件来处理这种向外调用，也可以使用生态系统中的解决方案。
 
 <a id="warning-always-allow" />
 
@@ -363,8 +364,8 @@ Kubernetes 允许你配置可包含多个 Webhook 的鉴权链。
 该链中的鉴权项可以具有明确定义的参数，这些参数可以按特定顺序检查请求，
 从而为你提供细粒度的控制，例如在失败时明确拒绝。
 
-配置文件方法甚至允许你指定 [CEL](/zh-cn/docs/reference/using-api/cel/)规则，
-在将请求发送到 Webhook 之前对其进行预过滤，从而帮助你防止不必要的调用。
+配置文件方法甚至允许你指定 [CEL](/zh-cn/docs/reference/using-api/cel/)
+规则，在将请求发送到 Webhook 之前对其进行预过滤，从而帮助你防止不必要的调用。
 修改配置文件时，API 服务器还会自动重新加载鉴权链。
 
 <!--
@@ -406,11 +407,23 @@ authorizers:
       # Same as setting `--authorization-webhook-cache-authorized-ttl` flag
       # Default: 5m0s
       authorizedTTL: 30s
+      # If set to false, 'authorized' responses from the webhook are not cached
+      # and the specified authorizedTTL is ignored/has no effect.
+      # Same as setting `--authorization-webhook-cache-authorized-ttl` flag to `0`.
+      # Note: Setting authorizedTTL to `0` results in its default value being used.
+      # Default: true
+      cacheAuthorizedRequests: true
       # The duration to cache 'unauthorized' responses from the webhook
       # authorizer.
       # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag
       # Default: 30s
       unauthorizedTTL: 30s
+      # If set to false, 'unauthorized' responses from the webhook are not cached
+      # and the specified unauthorizedTTL is ignored/has no effect.
+      # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag to `0`.
+      # Note: Setting unauthorizedTTL to `0` results in its default value being used.
+      # Default: true
+      cacheUnauthorizedRequests: true
       # Timeout for the webhook request
       # Maximum allowed is 30s.
       # Required, with no default.
@@ -506,10 +519,22 @@ authorizers:
       # 与设置 `--authorization-webhook-cache-authorized-ttl` 标志相同
       # 默认值：5m0s
       authorizedTTL: 30s
+      # 如果设置为 false，来自 Webhook 的 'authorized' 响应不会被缓存，
+      # 并且指定的 authorizedTTL 将被忽略/不起作用。
+      # 等同于将 `--authorization-webhook-cache-authorized-ttl` 标志设置为 `0`。
+      # 注意：将 authorizedTTL 设置为 `0` 会导致使用其默认值。
+      # 默认值：true
+      cacheAuthorizedRequests: true
       # 缓存来自 Webhook 鉴权组件的“未授权”响应的持续时间。
       # 与设置 `--authorization-webhook-cache-unauthorized-ttl` 标志相同
       # 默认值：30s
       unauthorizedTTL: 30s
+      # 如果设置为 false，来自 webhook 的 'unauthorized' 响应不会被缓存，
+      # 并且指定的 unauthorizedTTL 将被忽略/不起作用。
+      # 等同于将 `--authorization-webhook-cache-unauthorized-ttl` 标志设置为 `0`。
+      # 注意：将 unauthorizedTTL 设置为 `0` 会导致使用其默认值。
+      # 默认值：true
+      cacheUnauthorizedRequests: true
       # Webhook 请求超时
       # 允许的最大时间为 30 秒。
       # 必填，没有默认值。
@@ -554,7 +579,7 @@ authorizers:
         # 如果请求变量中 subjectAccessReviewVersion 指定的版本是 v1beta1，
         # 在评估 CEL 表达式之前，内容将转换为 v1 版本。
       #
-      # CEL 文档：https://kubernetes.io/docs/reference/using-api/cel/
+      # CEL 文档：https://kubernetes.io/zh-cn/docs/reference/using-api/cel/
       #
       # 仅向 Webhook 发送资源请求
       - expression: has(request.resourceAttributes)
@@ -734,8 +759,8 @@ As a system administrator, you should be cautious when deploying CustomResourceD
 that let users make changes to the above areas. These may open privilege escalations paths.
 Consider the consequences of this kind of change when deciding on your authorization controls.
 -->
-作为系统管理员，在部署允许用户更改上述区域的 CustomResourceDefinitions 时应谨慎行事，这些可能会打开特权升级路径。
-在配置你的鉴权控制时，请考虑这种变化的后果。
+作为系统管理员，在部署允许用户更改上述区域的 CustomResourceDefinitions 时应谨慎行事，
+这些可能会打开特权升级路径。在配置你的鉴权控制时，请考虑这种变化的后果。
 {{< /caution >}}
 
 <!--
@@ -801,7 +826,8 @@ no
 Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
 can list Pods in the Namespace `target`:
 -->
-类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账户是否可以列举名字空间 `target` 里的 Pod：
+类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账户是否可以列举名字空间
+`target` 里的 Pod：
 
 ```bash
 kubectl auth can-i list pods \
@@ -900,4 +926,3 @@ status:
 * 有关概述，请阅读[控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)。
 * 要了解有关准入控制的更多信息，请参阅[使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)。
 * 阅读更多关于 [Kubernetes 中的通用表达语言](/zh-cn/docs/reference/using-api/cel/)。
-

content/zh-cn/docs/reference/access-authn-authz/mutating-admission-policy.md

@@ -13,14 +13,31 @@ content_type: concept
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.32" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.34" state="beta" >}}
 <!-- due to feature gate history, use manual version specification here -->
 
 <!--
 This page provides an overview of _MutatingAdmissionPolicies_.
 -->
 本页概要介绍 **MutatingAdmissionPolicy（变更性准入策略）**。
 
+<!--
+MutatingAdmissionPolicies allow you change what happens when someone writes a change to the Kubernetes API.
+If you want to use declarative policies just to prevent a particular kind of change to resources (for example: protecting platform namespaces from deletion),
+[ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/)
+is
+a simpler and more effective alternative.
+
+To use the feature, enable the `MutatingAdmissionPolicy` feature gate (which is off by default) and set `--runtime-config=admissionregistration.k8s.io/v1beta1=true` on the kube-apiserver.
+-->
+MutatingAdmissionPolicies 允许你在有人向 Kubernetes API 写入变更时修改发生的操作。
+如果你只想使用声明式策略来阻止对资源的某种更改（例如：保护平台命名空间不被删除），
+[ValidatingAdmissionPolicy](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)
+是更简单且更有效的替代方案。
+
+要使用此特性，需要启用 `MutatingAdmissionPolicy` 特性门控（默认是关闭的），
+并在 kube-apiserver 上设置 `--runtime-config=admissionregistration.k8s.io/v1beta1=true`。
+
 <!-- body -->
 
 <!--
@@ -46,7 +63,8 @@ that can be parameterized and scoped to resources as needed by cluster administr
 变更操作可以通过使用[服务器端应用合并策略](/zh-cn/docs/reference/using-api/server-side-apply/#merge-strategy)所合并的**应用配置**来定义，
 也可以使用 [JSON 补丁](https://jsonpatch.com/)来定义。
 
-变更性准入策略的可配置能力很强，策略的编写者可以根据集群管理员的需要，定义参数化的策略以及限定到某类资源的策略。
+变更性准入策略的可配置能力很强，策略的编写者可以根据集群管理员的需要，
+定义参数化的策略以及限定到某类资源的策略。
 
 <!--
 ## What resources make a policy
@@ -128,7 +146,7 @@ passing through admission.
 -->
 `.spec.mutations` 字段由一系列表达式组成，这些表达式求值后将形成资源补丁。
 所生成的补丁可以是[应用配置](#patch-type-apply-configuration)或 [JSON 补丁](#patch-type-json-patch)。
-你不能将 mutations 设置为空列表。在对所有表达式求值后，API 服务器将所得到的变更应用到正在通过准入阶段的资源。
+你不能将 `mutations` 设置为空列表。在对所有表达式求值后，API 服务器将所得到的变更应用到正在通过准入阶段的资源。
 
 <!--
 To configure a mutating admission policy for use in a cluster, a binding is
@@ -245,8 +263,8 @@ CEL 表达式可以访问以 CEL 变量组织起来的 API 请求内容及一些
 The `apiVersion`, `kind`, `metadata.name`, `metadata.generateName` and `metadata.labels` are always accessible from the root of the  
 object. No other metadata properties are accessible.
 -->
-`apiVersion`、`kind`、`metadata.name`、`metadata.generateName` 和 `metadata.labels`
-始终可以从对象的根进行访问。其他元数据属性不可访问。
+`apiVersion`、`kind`、`metadata.name`、`metadata.generateName` 和
+`metadata.labels` 始终可以从对象的根进行访问。其他元数据属性不可访问。
 
 #### `JSONPatch` {#patch-type-json-patch}
 
@@ -299,7 +317,8 @@ To define a JSON object for the patch operation `value`, use CEL `Object` types.
 <!--
 To use strings containing '/' and '~' as JSONPatch path keys, use `jsonpatch.escapeKey()`. For example:
 -->
-要使用包含 '/' 和 '~' 的字符串作为 JSONPatch 路径键，可以使用 `jsonpatch.escapeKey()`。例如：
+要使用包含 '/' 和 '~' 的字符串作为 JSONPatch 路径键，可以使用
+`jsonpatch.escapeKey()`。例如：
 
 ```
   [
@@ -347,8 +366,8 @@ CEL expressions have access to the contents of the API request, organized into C
 -->
 CEL 表达式可以访问以 CEL 变量组织的 API 请求的内容及一些其他有用变量：
 
-- `object` - 来自传入请求的对象。对于 DELETE 请求，取值为 null。
-- `oldObject` - 现有对象。对于 CREATE 请求，取值为 null。
+- `object` - 来自传入请求的对象。对于 DELETE 请求，取值为 `null`。
+- `oldObject` - 现有对象。对于 CREATE 请求，取值为 `null`。
 - `request` - API 请求的属性。
 - `params` - 正被评估的策略绑定所引用的参数资源。仅在策略具有 `paramKind` 时填充。
 <!--
@@ -360,7 +379,7 @@ CEL 表达式可以访问以 CEL 变量组织的 API 请求的内容及一些其
 - `authorizer.requestResource` - A CEL ResourceCheck constructed from the `authorizer` and configured with the
   request resource.
 -->
-- `namespaceObject` - 传入对象所属的命名空间对象。对于集群范围的资源，取值为 null。
+- `namespaceObject` - 传入对象所属的命名空间对象。对于集群范围的资源，取值为 `null`。
 - `variables` - 组合变量的映射，包含从变量名称到其惰性评估值的映射。
   例如，名为 `foo` 的变量可以以 `variables.foo` 的形式访问。
 - `authorizer` - 一个 CEL 鉴权组件。可用于对请求的主体（用户或服务账户）执行鉴权检查。

content/zh-cn/docs/reference/access-authn-authz/validating-admission-policy.md

@@ -79,7 +79,8 @@ must be defined for a policy to have an effect.
 If a `ValidatingAdmissionPolicy` does not need to be configured via parameters, simply leave
 `spec.paramKind` in  `ValidatingAdmissionPolicy` not specified.
 -->
-至少要定义一个 `ValidatingAdmissionPolicy` 和一个相对应的 `ValidatingAdmissionPolicyBinding` 才能使策略生效。
+至少要定义一个 `ValidatingAdmissionPolicy` 和一个相对应的 `ValidatingAdmissionPolicyBinding`
+才能使策略生效。
 
 如果 `ValidatingAdmissionPolicy` 不需要参数配置，不设置 `ValidatingAdmissionPolicy` 中的
 `spec.paramKind` 即可。
@@ -92,7 +93,8 @@ with great caution. The following describes how to quickly experiment with Valid
 -->
 ## 开始使用验证准入策略  {#getting-started-with-validating-admission-policy}
 
-验证准入策略是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。下面介绍如何快速试验验证准入策略。
+验证准入策略是集群控制平面的一部分，你应该非常谨慎地编写和部署它们。
+下面介绍如何快速试验验证准入策略。
 
 <!--
 ### Creating a ValidatingAdmissionPolicy
@@ -619,11 +621,17 @@ CEL 表达式可以访问按 CEL 变量来组织的 Admission 请求/响应的
 - `authorizer.requestResource` - 针对请求资源（组、资源、（子资源）、命名空间、名称）所配置的鉴权检查的快捷方式。
 
 <!--
-The `apiVersion`, `kind`, `metadata.name` and `metadata.generateName` are always accessible from
-the root of the object. No other metadata properties are accessible.
+In CEL expressions, variables like `object` and `oldObject` are strongly-typed.
+You can access any field in the object's schema, such as `object.metadata.labels` and fields in `spec`.
+
+For any Kubernetes object, including schemaless Custom Resources, CEL guarantees access to a minimal set of properties:
+`apiVersion`, `kind`, `metadata.name`, and `metadata.generateName`.
 -->
-总是可以从对象的根访问的属性有 `apiVersion`、`kind`、`metadata.name` 和 `metadata.generateName`。
-其他元数据属性不能访问。
+在 CEL 表达式中，像 `object` 和 `oldObject` 这样的变量是强类型的。
+你可以访问对象模式中的任意字段，例如 `object.metadata.labels` 和 `spec` 中的字段。
+
+对于任意 Kubernetes 对象，包括无模式的自定义资源，CEL 保证至少可以访问以下一组属性：
+`apiVersion`、`kind`、`metadata.name` 和 `metadata.generateName`。
 
 <!--
 Equality on arrays with list type of 'set' or 'map' ignores element order, i.e. [1, 2] == [2, 1].
@@ -886,7 +894,7 @@ For example, given the following policy definition:
 <!--
 The status will yield the following information:
 -->
-status 字段将提供以下信息：
+`status` 字段将提供以下信息：
 
 ```yaml
 status: