From fda4f5b58e1e01292a77e8b2411a3cad2a461d16 Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Wed, 23 Sep 2020 01:41:51 -0700 Subject: [PATCH 1/2] Update link in page authorization --- content/zh/docs/reference/access-authn-authz/authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md index 3c2a08a817..49c8616b9a 100644 --- a/content/zh/docs/reference/access-authn-authz/authorization.md +++ b/content/zh/docs/reference/access-authn-authz/authorization.md @@ -29,7 +29,7 @@ cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API. --> 在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息， -请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/). +请参阅 [访问控制概述](/zh/docs/reference/access-authn-authz/controlling-access/). Kubernetes 期望 REST API 请求中常见的属性。 这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统， From a8542542a926b0fec6557e9e16fc4e1294acefbf Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Sat, 26 Sep 2020 19:37:56 -0700 Subject: [PATCH 2/2] Update more links --- .../docs/reference/access-authn-authz/abac.md | 13 +- .../admission-controllers.md | 36 +++--- .../access-authn-authz/authentication.md | 13 +- .../access-authn-authz/authorization.md | 24 ++-- .../access-authn-authz/bootstrap-tokens.md | 4 +- .../access-authn-authz/controlling-access.md | 10 +- .../extensible-admission-controllers.md | 24 ++-- .../docs/reference/access-authn-authz/node.md | 121 +++++++++--------- .../docs/reference/access-authn-authz/rbac.md | 28 ++-- .../service-accounts-admin.md | 4 +- .../reference/access-authn-authz/webhook.md | 96 +++++++------- 11 files changed, 179 insertions(+), 194 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/abac.md b/content/zh/docs/reference/access-authn-authz/abac.md index 7274053412..789e1cd3db 100644 --- a/content/zh/docs/reference/access-authn-authz/abac.md +++ b/content/zh/docs/reference/access-authn-authz/abac.md @@ -63,7 +63,7 @@ properties: - Non-resource-matching properties: - `nonResourcePath`, type string; non-resource request paths. - Ex: `/version` or `/apis` - - Wildcard: + - Wildcard: - `*` matches all non-resource requests. - `/foo/*` matches all subpaths of `/foo/`. - `readonly`, type boolean, when true, means that the Resource-matching policy only applies to get, list, and watch operations, Non-resource-matching policy only applies to get operation. @@ -73,7 +73,7 @@ properties: 基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。 -此文件格式是 [JSON Lines](http://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。 +此文件格式是 [JSON Lines](https://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。 每一行都是一个策略对象，策略对象是具有以下属性的映射： @@ -213,7 +213,7 @@ Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点来发现服务资源类 {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}} ``` --> - + ## 例子 {#examples} 1. Alice 可以对所有资源做任何事情： @@ -270,7 +270,7 @@ system:serviceaccount:: --> -[完整文件示例](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl) +[完整文件示例](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl) ## 服务帐户的快速说明 @@ -287,7 +287,7 @@ Creating a new namespace leads to the creation of a new service account in the f system:serviceaccount::default ``` -For example, if you wanted to grant the default service account (in the `kube-system` namespace) full +For example, if you wanted to grant the default service account (in the `kube-system` namespace) full privilege to the API using ABAC, you would add this line to your policy file: ```json @@ -310,6 +310,3 @@ system:serviceaccount::default ``` 需要重新启动 apiserver 以获取新的策略行。 - - - diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index 93be72db24..bf63ab206b 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -48,7 +48,7 @@ webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#a which are configured in the API. --> -准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 +准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成，并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们根据 API 中的配置，分别执行变更和验证[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 -关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/docs/concepts/storage/persistent-volumes/)。 +关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 ### DefaultTolerationSeconds {#defaulttolerationseconds} @@ -395,7 +395,7 @@ add these tolerations. 该插件有助于创建可扩展资源的专用节点。 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， -那他们应该以扩展资源名称作为键名，[为节点设置污点](/docs/concepts/configuration/taint-and-toleration/#example-use-cases)。 +那他们应该以扩展资源名称作为键名，[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中，用户不必再手动添加这些容忍。 ### ImagePolicyWebhook {#imagepolicywebhook} @@ -505,7 +505,7 @@ plugins: The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS. --> -ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。 +ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件，该文件设置了到后端的连接，要求后端使用 TLS 进行通信。 -HTTP 更多的配置，请参阅 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 文档。 +HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。 -请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/docs/tasks/configure-pod-container/limit-range/)了解更多细节。 +请查看 [limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) 和 [Limit Range 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)了解更多细节。 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}} @@ -852,7 +852,7 @@ Starting from 1.11, this admission controller is disabled by default. 该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS）定义的 PersistentVolumes 中。 这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签，以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/docs/tasks/administer-cluster/running-cloud-controller/)接管。 +PersistentVolumeLabel 已被废弃，标记持久卷已由[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 从 1.11 开始，默认情况下禁用此准入控制器。 ### PodNodeSelector {#podnodeselector} @@ -1005,7 +1005,7 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). --> -关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +关于持久化卷申领的更多信息，请参见 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PodPreset {#podpreset} @@ -1037,7 +1037,7 @@ extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`). See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/) for more information. --> -查看 [Pod 安全策略文档](/docs/concepts/policy/pod-security-policy/)了解更多细节。 +查看 [Pod 安全策略文档](/zh/docs/concepts/policy/pod-security-policy/)了解更多细节。 ### PodTolerationRestriction {#podtolerationrestriction} @@ -1094,7 +1094,7 @@ objects in your Kubernetes deployment, you MUST use this admission controller to -请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/docs/concepts/policy/resource-quotas/)了解更多细节。 +请查看 [resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 -该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/docs/user-guide/security-context) 字段的 pod。 -如果集群没有使用 [pod 安全策略](/docs/user-guide/pod-security-policy)来限制安全上下文所能获取的值集，那么应该启用这个功能。 +该准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 字段的 pod。 +如果集群没有使用 [pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)来限制安全上下文所能获取的值集，那么应该启用这个功能。 ### ServiceAccount {#serviceaccount} @@ -1127,7 +1127,7 @@ This admission controller will deny any pod that attempts to set certain escalat This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts). We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects. --> -该准入控制器实现了 [serviceAccounts](/docs/user-guide/service-accounts) 的自动化。 +该准入控制器实现了 [serviceAccounts](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。 如果您打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议您使用这个准入控制器。 ### StorageObjectInUseProtection @@ -1135,7 +1135,7 @@ We strongly recommend using this admission controller if you intend to make use -`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 +`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC）或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。有关更多详细信息，请参考[保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 ### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}} @@ -1179,7 +1179,7 @@ Yes. For Kubernetes version 1.10 and later, the recommended admission controller --> ## 有推荐的准入控制器吗？ -有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 +有，对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。 因此您无需显式指定它们。您可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 {{< note >}} @@ -1217,5 +1217,3 @@ in the mutating phase. admission controllers ran in the exact order specified. --> 对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。 - - diff --git a/content/zh/docs/reference/access-authn-authz/authentication.md b/content/zh/docs/reference/access-authn-authz/authentication.md index 64c70cf898..3588333018 100644 --- a/content/zh/docs/reference/access-authn-authz/authentication.md +++ b/content/zh/docs/reference/access-authn-authz/authentication.md @@ -66,7 +66,7 @@ for more details about this. 使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=bob"）来 确定用户名。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对 某资源执行特定的操作。进一步的细节可参阅 -[证书请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user) +[证书请求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user) 下普通用户主题。 -服务账号通常由 API 服务器自动创建并通过 `ServiceAccount` +服务账号通常由 API 服务器自动创建并通过 `ServiceAccount` [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 关联到集群中运行的 Pod 上。 持有者令牌会挂载到 Pod 中可预知的为之，允许集群内进程与 API 服务器通信。 @@ -550,7 +550,7 @@ from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_ as a bearer token. See [above](#putting-a-bearer-token-in-a-request) for how the token is included in a request. --> -要识别用户，身份认证组件使用 OAuth2 +要识别用户，身份认证组件使用 OAuth2 [令牌响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) 中的 `id_token`（而非 `access_token`）作为持有者令牌。 关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。 @@ -654,7 +654,7 @@ Kubernetes does not provide an OpenID Connect Identity Provider. You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)). Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), -[Keycloak](https://github.com/keycloak/keycloak), +[Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison). --> @@ -814,7 +814,7 @@ The configuration file uses the [kubeconfig](/docs/concepts/configuration/organi file format. Within the file, `clusters` refers to the remote service and `users` refers to the API server webhook. An example would be: --> -配置文件使用 [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +配置文件使用 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件的格式。文件中，`clusters` 指代远程服务，`users` 指代远程 API 服务 Webhook。下面是一个例子： @@ -1455,7 +1455,7 @@ Relative command paths are interpreted as relative to the directory of the confi KUBECONFIG is set to `/home/jane/kubeconfig` and the exec command is `./bin/example-client-go-exec-plugin`, the binary `/home/jane/bin/example-client-go-exec-plugin` is executed. --> -解析相对命令路径时，kubectl 将其视为与配置文件比较而言的相对路径。 +解析相对命令路径时，kubectl 将其视为与配置文件比较而言的相对路径。 如果 KUBECONFIG 被设置为 `/home/jane/kubeconfig`，而 exec 命令为 `./bin/example-client-go-exec-plugin`，则要执行的可执行文件为 `/home/jane/bin/example-client-go-exec-plugin`。 @@ -1561,4 +1561,3 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact: } } ``` - diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh/docs/reference/access-authn-authz/authorization.md index 49c8616b9a..a2b5e22207 100644 --- a/content/zh/docs/reference/access-authn-authz/authorization.md +++ b/content/zh/docs/reference/access-authn-authz/authorization.md @@ -85,12 +85,12 @@ Kubernetes 仅审查以下 API 请求属性： * **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。 * **API** - 指示请求是否针对 API 资源。 * **Request path** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。 - * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。 + * **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/zh/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。 * **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求。 * **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用 `get`，`update`，`patch` 和 `delete` 动词的资源请求，您必须提供资源名称。 * **Subresource** - 正在访问的子资源（仅限资源请求）。 * **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。 - * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/docs/concepts/overview/kubernetes-api/)。 + * **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/concepts/overview/kubernetes-api/)。 ## 授权模块 - * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/). - * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/docs/reference/access-authn-authz/abac/)。 - * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/docs/reference/access-authn-authz/rbac/)。 + * **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/zh/docs/reference/access-authn-authz/node/). + * **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。 + * **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。 * 当指定的 RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。 * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 apiserver 。 - * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/docs/reference/access-authn-authz/webhook/)。 + * **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。 -管理员可以将此与[用户模拟](/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。 +管理员可以将此与[用户模拟](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。 ```bash $ kubectl auth can-i list secrets --namespace dev --as dave @@ -300,5 +300,5 @@ mode. * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/). * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). --> -* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)。 -* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/)。 +* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)。 +* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 diff --git a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md index 77ca6f32d5..c36f1f9bba 100644 --- a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -9,9 +9,9 @@ title: 使用启动引导令牌（Bootstrap Tokens）认证 ## 概述 启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。 -它被设计成能够支持 [`kubeadm`](/docs/admin/kubeadm/)，但是也可以被用在其他的案例中以便用户在 +它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，但是也可以被用在其他的案例中以便用户在 不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS -Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 系统进行工作。 +Bootstrapping](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统进行工作。 启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于 `kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。 diff --git a/content/zh/docs/reference/access-authn-authz/controlling-access.md b/content/zh/docs/reference/access-authn-authz/controlling-access.md index edfc3aab85..933072d606 100644 --- a/content/zh/docs/reference/access-authn-authz/controlling-access.md +++ b/content/zh/docs/reference/access-authn-authz/controlling-access.md @@ -5,7 +5,7 @@ approvers: title: Kubernetes API 访问控制 --- -用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/docs/user-guide/accessing-the-cluster)。 用户和 [Kubernetes 服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 +用户通过 `kubectl`、客户端库或者通过发送 REST 请求[访问 API](/zh/docs/tasks/access-application-cluster/access-cluster/)。 用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行 API 访问。 请求到达 API 服务器后会经过几个阶段，具体说明如图： ![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) @@ -20,7 +20,7 @@ API 服务器会提供一份证书。 该证书一般是自签名的， 所以 一旦 TLS 连接建立，HTTP 请求就进入到了认证的步骤。即图中的步骤 **1** 。 集群创建脚本或集群管理员会为 API 服务器配置一个或多个认证模块。 -更具体的认证相关的描述详见[这里](/docs/admin/authentication/)。 +更具体的认证相关的描述详见[这里](/zh/docs/reference/access-authn-authz/authentication/)。 认证步骤的输入是整个 HTTP 请求，但这里通常只是检查请求头和 / 或客户端证书。 @@ -73,13 +73,13 @@ Bootstrap Tokens，以及 JWT Tokens（用于服务账户）。 } } ``` -如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。 +如果 Bob 对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果 Bob 请求读取 （`get`）其他命名空间，例如 `projectFish` 下的对象，其授权也会被拒绝。 Kubernetes 的授权要求使用通用的 REST 属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用 REST 格式是必要的，因为除 Kubernetes 外，这些访问控制系统还可能与其他的 API 进行交互。 Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhook 模式。 管理员创建集群时，会配置 API 服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes 将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝（HTTP 状态码 403）。 -要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。 +要了解更多的 Kubernetes 授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/zh/docs/reference/access-authn-authz/authorization/)。 ## 准入控制 @@ -96,7 +96,7 @@ Kubernetes 支持多种授权模块，例如 ABAC 模式，RBAC 模式和 Webhoo 除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。 -可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。 +可用的准入控制模块描述 [如下](/zh/docs/reference/access-authn-authz/admission-controllers/)。 一旦请求通过所有准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储 （如步骤 **4**）。 diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md index 4b0fcf0584..9e42aa7bdf 100644 --- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -18,7 +18,7 @@ In addition to [compiled-in admission plugins](/docs/reference/access-authn-auth admission plugins can be developed as extensions and run as webhooks configured at runtime. This page describes how to build, configure, use, and monitor admission webhooks. --> -除了[内置的 admission 插件](/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。 +除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。 此页面描述了如何构建、配置、使用和监视 admission webhook。 @@ -37,7 +37,7 @@ and Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. --> Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 -可以定义两种类型的 admission webhook，即 [validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。 +可以定义两种类型的 admission webhook，即 [validating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。 Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。 -有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。 +有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。 -有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。 +有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。 +--> 这是配置为调用 URL 的 mutating Webhook 的示例（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）： {{< tabs name="MutatingWebhookConfiguration_url" >}} @@ -1793,7 +1793,7 @@ capturing if a request object is mutated by the invocation, and optionally gener patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of its execution, which is then pre-processed according to a certain policy and written to a backend. --> -在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/docs/tasks/debug-application-cluster/audit/)操作。 +在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。 每个调用都会生成一个审计注解，记述请求对象是否发生改变，可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。 针对给定请求的给定执行阶段，注解被添加到审计事件中，然后根据特定策略进行预处理并写入后端。 @@ -2150,7 +2150,7 @@ If side effects are required during the admission evaluation, they must be suppr set to `NoneOnDryRun`. See [Side effects](#side-effects) for more detail. --> ### Side Effects - + 建议 admission webhook 应尽可能避免副作用，这意味着该 admission webhook 仅对发送给他们的 `AdmissionReview` 的内容起作用，并且不要进行额外更改。 如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为 `None`。 @@ -2173,5 +2173,3 @@ plane, exclude the `kube-system` namespace from being intercepted using a `kube-system` 命名空间包含由 Kubernetes 系统创建的对象，例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。 意外更改或拒绝 `kube-system` 命名空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。 如果您的 admission webhook 不想修改 Kubernetes 控制平面的行为，请使用 [`namespaceSelector`](#matching-requests-namespaceselector) 避免拦截 `kube-system` 命名空间。 - - diff --git a/content/zh/docs/reference/access-authn-authz/node.md b/content/zh/docs/reference/access-authn-authz/node.md index 22573d5e82..dc1c86ee4f 100644 --- a/content/zh/docs/reference/access-authn-authz/node.md +++ b/content/zh/docs/reference/access-authn-authz/node.md @@ -3,7 +3,7 @@ title: 使用 Node 鉴权 content_type: concept weight: 90 --- - 节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求进行鉴权。 - ## 概述 - 节点鉴权器允许 kubelet 执行 API 操作。包括： - 读取操作： - * services * endpoints * nodes * pods -* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷 +* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷 - 写入操作： - * 节点和节点状态（启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点） * Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod) * 事件 - 鉴权相关操作： - * 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限 * 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力 - 在将来的版本中，节点鉴权器可能会添加或删除权限，以确保 kubelet 具有正确操作所需的最小权限集。 - 为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中，用户名为 `system:node:`。 -上述的组名和用户名格式要与 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。 - 要启用节点授权器，请使用 `--authorization-mode = Node` 启动 apiserver。 - -要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。 - ## 迁移考虑因素 - ### 在 `system:nodes` 组之外的 Kubelet - `system:nodes` 组之外的 kubelet 不会被 `Node` 鉴权模式授权，并且需要继续通过当前授权它们的机制来授权。 节点准入插件不会限制来自这些 kubelet 的请求。 - ### 具有无差别用户名的 Kubelet - 在一些部署中，kubelet 具有 `system:nodes` 组的凭证，但是无法给出它们所关联的节点的标识，因为它们没有 `system:node:...` 格式的用户名。 这些 kubelet 不会被 `Node` 授权模式授权，并且需要继续通过当前授权它们的任何机制来授权。 - 因为默认的节点标识符实现不会把它当作节点身份标识，`NodeRestriction` 准入插件会忽略来自这些 kubelet 的请求。 - ### 相对于以前使用 RBAC 的版本的更新 - -升级的 1.7 之前的使用 [RBAC](/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。 - 如果集群管理员希望开始使用 `Node` 鉴权器和 `NodeRestriction` 准入插件来限制节点对 API 的访问，这一需求可以通过下列操作来完成且不会影响已部署的应用： - @@ -165,40 +165,39 @@ to limit node access to the API, that can be done non-disruptively: 2. 确保所有 kubelet 的凭据符合组/用户名要求 3. 审核 apiserver 日志以确保 `Node` 鉴权器不会拒绝来自 kubelet 的请求（日志中没有持续的 `NODE DENY` 消息） 4. 删除 `system:node` 集群角色绑定 - ### RBAC 节点权限 - -在 1.6 版本中，当使用 [RBAC 鉴权模式](/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。 - 在 1.7 版本中，不再推荐将 `system:nodes` 组自动绑定到 `system:node` 角色，因为节点鉴权器通过对 secret 和 configmap 访问的额外限制完成了相同的任务。 如果同时启用了 `Node` 和 `RBAC` 授权模式，1.7 版本则不会创建 `system:nodes` 组到 `system:node` 角色的自动绑定。 - 在 1.8 版本中，绑定将根本不会被创建。 - 使用 RBAC 时，将继续创建 `system:node` 集群角色，以便与将其他用户或组绑定到该角色的部署方法兼容。 - - diff --git a/content/zh/docs/reference/access-authn-authz/rbac.md b/content/zh/docs/reference/access-authn-authz/rbac.md index 3d35e4e8bb..8fa82a367d 100644 --- a/content/zh/docs/reference/access-authn-authz/rbac.md +++ b/content/zh/docs/reference/access-authn-authz/rbac.md @@ -244,7 +244,7 @@ roleRef: ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 +# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 kind: RoleBinding metadata: name: read-secrets @@ -261,7 +261,7 @@ roleRef: ### 控制器角色 {#controller-roles} -[Kubernetes 控制器管理器](/docs/admin/kube-controller-manager/) 运行核心控制环。 +[Kubernetes 控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 运行核心控制环。 当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。 每个控制环都有相应的、前缀为 `system:controller:` 的角色。 如果控制管理器启动时未设置 `--use-service-account-credentials`， @@ -1410,7 +1410,7 @@ containing that permission. To allow a user to create/update roles: * implicitly, by giving them those permissions (if they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden) * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer) -A user can only create/update a role binding if they already have all the permissions contained in the referenced role +A user can only create/update a role binding if they already have all the permissions contained in the referenced role (at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role. For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding` to a role that grants that permission. To allow a user to create/update role bindings: @@ -1422,7 +1422,7 @@ to a role that grants that permission. To allow a user to create/update role bin --> ## 初始化与预防权限升级 -RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 +RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权器（RBAC authorizer）未启用的状态下依然可以正常工作。 用户只有在符合下列条件之一的情况下，才能创建/更新角色: @@ -2078,7 +2078,7 @@ in the server logs, you can remove the ABAC authorizer. ### 平行鉴权 同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含 -[现有的 ABAC 策略](/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： +[现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： ``` --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json @@ -2134,5 +2134,3 @@ kubectl create clusterrolebinding permissive-binding \ --group=system:serviceaccounts ``` {{< /warning >}} - - diff --git a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md index 0cf89e8ec7..cb559d0505 100644 --- a/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/zh/docs/reference/access-authn-authz/service-accounts-admin.md @@ -7,7 +7,7 @@ approvers: title: 管理 Service Accounts --- -*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。* +*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/zh/docs/tasks/configure-pod-container/configure-service-account/)中的信息。* *对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述 service accounts，有时这些不完善的特性也会被提及。* @@ -32,7 +32,7 @@ Kubernetes 区分用户账户和服务账户的概念主要基于以下原因： ### 服务账户准入控制器 -对 pod 的改动通过一个被称为 [Admission Controller](/docs/admin/admission-controllers) 的插件来实现。它是 apiserver 的一部分。 +对 pod 的改动通过一个被称为 [Admission Controller](/zh/docs/reference/access-authn-authz/admission-controllers/) 的插件来实现。它是 apiserver 的一部分。 当 pod 被创建或更新时，它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 )，当 pod 被创建或更新时它会进行以下动作： 1. 如果该 pod 没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。 diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh/docs/reference/access-authn-authz/webhook.md index a77f9df2b5..8cfdc91592 100644 --- a/content/zh/docs/reference/access-authn-authz/webhook.md +++ b/content/zh/docs/reference/access-authn-authz/webhook.md @@ -8,7 +8,7 @@ title: Webhook 模式 content_type: concept weight: 95 --- - - WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。 - 具体来说，当在判断用户权限时，`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。 - ## 配置文件格式 - `Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。 - -配置文件的格式使用 [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。 +配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。 - 使用 HTTPS 客户端认证的配置例子： - ```yaml # Kubernetes API 版本 @@ -119,31 +119,31 @@ contexts: name: webhook ``` - ## 请求载荷 - 在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 - -需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--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`)。 - 一个请求内容的例子： @@ -167,10 +167,10 @@ An example request body: } ``` - 期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回: ```json @@ -183,17 +183,17 @@ the request and respond to either allow or disallow access. The response body's } ``` - 为了禁止访问，有两种方法。 - 在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求"无意见"，但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回: @@ -208,11 +208,11 @@ request is forbidden. The webhook would return: } ``` - 第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回: @@ -228,8 +228,8 @@ The webhook would return: } ``` - 对于非资源的路径访问是这么发送的: @@ -251,25 +251,21 @@ Access to non-resource paths are sent as: } ``` - 非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`, `/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和 `/version`。客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。 - 更多信息可以参考 authorization.v1beta1 API 对象和[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。 - - - -