Switch language name 'zh' to 'zh-cn'

This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name. - The upstream docsy theme changed the language name, leading to many warnings during site build; The side-effect is that the i18n strings are no longer working. - We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc. There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc. We will lock up changes to zh/zh-cn pages for the moment, until this one gets in. This PR is based on commit cdad0a7342.
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
@@ -0,0 +1,271 @@
+---
+title: Webhook 模式
+content_type: concept
+weight: 95
+---
+<!--
+reviewers:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: Webhook Mode
+content_type: concept
+weight: 95
+-->
+
+<!-- overview -->
+<!--
+A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
+-->
+WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。
+
+
+<!-- body -->
+<!--
+When specified, mode `Webhook` causes Kubernetes to query an outside REST
+service when determining user privileges.
+-->
+具体来说，当在判断用户权限时，`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。
+
+<!--
+## Configuration File Format
+-->
+## 配置文件格式 {#configuration-file-format}
+
+<!--
+Mode `Webhook` requires a file for HTTP configuration, specify by the
+`--authorization-webhook-config-file=SOME_FILENAME` flag.
+-->
+`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
+
+<!--
+The configuration file uses the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+file format. Within the file "users" refers to the API Server webhook and
+"clusters" refers to the remote service.
+-->
+配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
+在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。
+
+<!--
+A configuration example which uses HTTPS client auth:
+-->
+使用 HTTPS 客户端认证的配置例子：
+
+<!--
+```yaml
+# Kubernetes API version
+apiVersion: v1
+# kind of the API object
+kind: Config
+# clusters refers to the remote service.
+clusters:
+  - name: name-of-remote-authz-service
+    cluster:
+      # CA for verifying the remote service.
+      certificate-authority: /path/to/ca.pem
+      # URL of remote service to query. Must use 'https'. May not include parameters.
+      server: https://authz.example.com/authorize
+
+# users refers to the API Server's webhook configuration.
+users:
+  - name: name-of-api-server
+    user:
+      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
+      client-key: /path/to/key.pem          # key matching the cert
+
+# kubeconfig files require a context. Provide one for the API Server.
+current-context: webhook
+contexts:
+- context:
+    cluster: name-of-remote-authz-service
+    user: name-of-api-server
+  name: webhook
+```
+-->
+```yaml
+# Kubernetes API 版本
+apiVersion: v1
+# API 对象种类
+kind: Config
+# clusters 代表远程服务。
+clusters:
+  - name: name-of-remote-authz-service
+    cluster:
+      # 对远程服务进行身份认证的 CA。
+      certificate-authority: /path/to/ca.pem
+      # 远程服务的查询 URL。必须使用 'https'。
+      server: https://authz.example.com/authorize
+
+# users 代表 API 服务器的 webhook 配置
+users:
+  - name: name-of-api-server
+    user:
+      client-certificate: /path/to/cert.pem # webhook plugin 使用 cert
+      client-key: /path/to/key.pem          # cert 所对应的 key
+
+# kubeconfig 文件必须有 context。需要提供一个给 API 服务器。
+current-context: webhook
+contexts:
+- context:
+    cluster: name-of-remote-authz-service
+    user: name-of-api-server
+  name: webhook
+```
+
+<!--
+## Request Payloads
+-->
+## 请求载荷 {#request-payloads}
+
+<!--
+When faced with an authorization decision, the API Server POSTs a JSON-
+serialized `authorization.k8s.io/v1beta1` `SubjectAccessReview` object describing the
+action. This object contains fields describing the user attempting to make the
+request, and either details about the resource being accessed or requests
+attributes.
+-->
+在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview`
+对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。
+
+<!--
+Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
+as other Kubernetes API objects. Implementers should be aware of looser
+compatibility promises for beta objects and check the "apiVersion" field of the
+request to ensure correct deserialization. Additionally, the API Server must
+enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
+-->
+需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。
+实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。
+此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。
+
+<!--
+An example request body:
+-->
+一个请求内容的例子：
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "kittensandponies",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    },
+    "user": "jane",
+    "group": [
+      "group1",
+      "group2"
+    ]
+  }
+}
+```
+
+<!--
+The remote service is expected to fill the `status` field of
+the request and respond to either allow or disallow access. The response body's
+`spec` field is ignored and may be omitted. A permissive response would return:
+-->
+期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": true
+  }
+}
+```
+
+<!--
+For disallowing access there are two methods.
+-->
+为了禁止访问，有两种方法。
+
+<!--
+The first method is preferred in most cases, and indicates the authorization
+webhook does not allow, or has "no opinion" about the request, but if other
+authorizers are configured, they are given a chance to allow the request.
+If there are no other authorizers, or none of them allow the request, the
+request is forbidden. The webhook would return:
+-->
+在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求 “无意见”。
+但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回：
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": false,
+    "reason": "user does not have read access to the namespace"
+  }
+}
+```
+
+<!--
+The second method denies immediately, short-circuiting evaluation by other
+configured authorizers. This should only be used by webhooks that have
+detailed knowledge of the full authorizer configuration of the cluster.
+The webhook would return:
+-->
+第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回：
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": false,
+    "denied": true,
+    "reason": "user does not have read access to the namespace"
+  }
+}
+```
+
+<!--
+Access to non-resource paths are sent as:
+-->
+对于非资源的路径访问是这么发送的:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "nonResourceAttributes": {
+      "path": "/debug",
+      "verb": "get"
+    },
+    "user": "jane",
+    "group": [
+      "group1",
+      "group2"
+    ]
+  }
+}
+```
+
+<!--
+Non-resource paths include: `/api`, `/apis`, `/metrics`,
+`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
+`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
+and `/version` to discover what resources and versions are present on the server.
+Access to other non-resource paths can be disallowed without restricting access
+to the REST api.
+-->
+非资源类的路径包括：`/api`、`/apis`、`/metrics`、`/logs`、`/debug`、
+`/healthz`、`/livez`、`/openapi/v2`、`/readyz`、和 `/version`。
+客户端需要访问 `/api`、`/api/*`、`/apis`、`/apis/*` 和 `/version` 以便
+能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
+
+<!--
+For further documentation refer to the authorization.v1beta1 API objects and
+[webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
+-->
+更多信息可以参考 authorization.v1beta1 API 对象和 [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
+