Merge pull request #24066 from gaoguangze111/update-link-authorization
Update link in page authorizationpull/24222/head
Kubernetes Prow Robot
GitHub
commit
fc2ee814d6
|
|
@ -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:<namespace>:<serviceaccountname>
|
|||
|
||||
-->
|
||||
|
||||
[完整文件示例](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:<namespace>: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:<namespace>:default
|
|||
```
|
||||
|
||||
需要重新启动 apiserver 以获取新的策略行。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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)。
|
||||
|
||||
|
||||
<!--
|
||||
|
|
@ -233,7 +233,7 @@ See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentatio
|
|||
storage classes and how to mark a storage class as default.
|
||||
-->
|
||||
|
||||
关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/docs/concepts/storage/persistent-volumes/)。
|
||||
关于持久化卷和存储类，以及如何将存储类标记为默认，请参见[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
### DefaultTolerationSeconds {#defaulttolerationseconds}
|
||||
|
||||
|
|
@ -400,7 +400,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}
|
||||
|
|
@ -510,7 +510,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 进行通信。
|
||||
|
||||
<!--
|
||||
The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
|
||||
|
|
@ -555,7 +555,7 @@ users:
|
|||
For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
|
||||
-->
|
||||
|
||||
HTTP 更多的配置，请参阅 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 文档。
|
||||
HTTP 更多的配置，请参阅 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。
|
||||
|
||||
<!--
|
||||
#### Request Payloads
|
||||
|
|
@ -688,7 +688,7 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
|||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
|
||||
-->
|
||||
|
||||
请查看 [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" >}}
|
||||
|
|
@ -859,7 +859,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}
|
||||
|
|
@ -1012,7 +1012,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}
|
||||
|
||||
|
|
@ -1044,7 +1044,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}
|
||||
|
||||
|
|
@ -1101,7 +1101,7 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
|
|||
<!--
|
||||
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
|
||||
-->
|
||||
请查看 [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/)了解更多细节。
|
||||
|
||||
|
||||
<!--
|
||||
|
|
@ -1117,17 +1117,17 @@ for more information.
|
|||
### 容器运行时类 {#runtimeclass}
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
[容器运行时类](/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
|
||||
[容器运行时类](/zh/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。
|
||||
|
||||
详情请参见 [Pod 开销](/docs/concepts/configuration/pod-overhead/)。
|
||||
详情请参见 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/)。
|
||||
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
<!--
|
||||
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
|
||||
-->
|
||||
该准入控制器将拒绝任何试图设置特定提升 [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}
|
||||
|
||||
|
|
@ -1135,7 +1135,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
|
||||
|
|
@ -1143,7 +1143,7 @@ We strongly recommend using this admission controller if you intend to make use
|
|||
<!--
|
||||
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
|
||||
-->
|
||||
`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" >}}
|
||||
|
|
@ -1189,7 +1189,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 >}}
|
||||
|
|
@ -1227,5 +1227,3 @@ in the mutating phase.
|
|||
admission controllers ran in the exact order specified.
|
||||
-->
|
||||
对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
下普通用户主题。
|
||||
|
||||
<!--
|
||||
|
|
@ -387,7 +387,7 @@ mounted into pods at well-known locations, and allow in-cluster processes to
|
|||
talk to the API server. Accounts may be explicitly associated with pods using the
|
||||
`serviceAccountName` field of a `PodSpec`.
|
||||
-->
|
||||
服务账号通常由 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:
|
|||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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 授权适用于现有的组织范围或云提供商范围的访问控制系统，
|
||||
|
|
@ -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/)。
|
||||
|
||||
<!--
|
||||
## Determine the Request Verb
|
||||
|
|
@ -128,9 +128,9 @@ DELETE | delete (单个资源)，deletecollection (资源集合)
|
|||
|
||||
Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如：
|
||||
|
||||
* [Pod 安全策略](/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
|
||||
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
|
||||
* [认证](/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
|
||||
* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
|
||||
* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
|
||||
* [认证](/zh/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
|
||||
|
||||
<!--
|
||||
## Authorization Modules
|
||||
|
|
@ -143,12 +143,12 @@ Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例
|
|||
-->
|
||||
|
||||
## 授权模块
|
||||
* **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/)。
|
||||
|
||||
<!--
|
||||
#### Checking API Access
|
||||
|
|
@ -173,7 +173,7 @@ no
|
|||
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||
to determine what action other users can perform.
|
||||
-->
|
||||
管理员可以将此与[用户模拟](/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/)。
|
||||
|
|
|
|||
|
|
@ -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 服务器上的启动引导的认证器读取。
|
||||
|
|
|
|||
|
|
@ -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 服务器的对象以执行自定义的设置默认值操作。
|
||||
|
||||
<!--
|
||||
|
|
@ -67,7 +67,7 @@ In the following, we describe how to quickly experiment with admission webhooks.
|
|||
### 尝试 admission webhook
|
||||
|
||||
admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。
|
||||
如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
|
||||
如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
|
||||
在下文中，我们将介绍如何快速试验 admission webhook。
|
||||
|
||||
<!--
|
||||
|
|
@ -88,7 +88,7 @@ admission webhook 本质上是集群控制平面的一部分。您应该非常
|
|||
* 确保 Kubernetes 集群版本至少为 v1.16（以便使用 `admissionregistration.k8s.io/v1` API） 或者 v1.9 （以便使用 `admissionregistration.k8s.io/v1beta1` API）。
|
||||
|
||||
* 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
|
||||
[这里](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
[这里](/zh/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
是一组推荐的 admission 控制器，通常可以启用。
|
||||
|
||||
* 确保启用了 `admissionregistration.k8s.io/v1beta1` API。
|
||||
|
|
@ -281,7 +281,7 @@ the webhooks. There are three steps to complete the configuration.
|
|||
* 启动 apiserver 时，通过 `--admission-control-config-file` 参数指定准入控制配置文件的位置。
|
||||
|
||||
* 在准入控制配置文件中，指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。
|
||||
凭证存储在 kubeConfig 文件中（是的，与 kubectl 使用的模式相同），因此字段名称为 `kubeConfigFile`。
|
||||
凭证存储在 kubeConfig 文件中（是的，与 kubectl 使用的模式相同），因此字段名称为 `kubeConfigFile`。
|
||||
以下是一个准入控制配置文件示例：
|
||||
|
||||
<!--
|
||||
|
|
@ -748,7 +748,7 @@ For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of
|
|||
当允许请求时，mutating admission webhook 也可以选择修改传入的对象。
|
||||
这是通过在响应中使用 `patch` 和 `patchType` 字段来完成的。
|
||||
当前唯一支持的 `patchType` 是 `JSONPatch`。
|
||||
有关更多详细信息，请参见 [JSON patch](http://jsonpatch.com/)。
|
||||
有关更多详细信息，请参见 [JSON patch](https://jsonpatch.com/)。
|
||||
对于 `patchType: JSONPatch`，`patch` 字段包含一个以 base64 编码的 JSON patch 操作数组。
|
||||
|
||||
<!--
|
||||
|
|
@ -1060,7 +1060,7 @@ webhooks:
|
|||
<!--
|
||||
See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
|
||||
-->
|
||||
有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
|
||||
有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
|
||||
|
||||
<!--
|
||||
### Matching requests: namespaceSelector
|
||||
|
|
@ -1187,7 +1187,7 @@ webhooks:
|
|||
<!--
|
||||
See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
|
||||
-->
|
||||
有关标签选择器的更多示例，请参见[标签](/docs/concepts/overview/working-with-objects/labels)。
|
||||
有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
|
||||
|
||||
<!--
|
||||
### Matching requests: matchPolicy
|
||||
|
|
@ -1367,7 +1367,7 @@ Fragments ("#...") and query parameters ("?...") are also not allowed.
|
|||
<!--
|
||||
Here is an example of a mutating webhook configured to call a URL
|
||||
(and expects the TLS certificate to be verified using system trust roots, so does not specify a caBundle):
|
||||
-->
|
||||
-->
|
||||
这是配置为调用 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` 命名空间。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 使用 Node 鉴权
|
|||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
<!--
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- timstclair
|
||||
|
|
@ -18,145 +18,145 @@ weight: 90
|
|||
|
||||
<!-- overview -->
|
||||
节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求进行鉴权。
|
||||
<!--
|
||||
<!--
|
||||
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
|
||||
-->
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## 概述
|
||||
<!--
|
||||
## Overview
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
|
||||
节点鉴权器允许 kubelet 执行 API 操作。包括：
|
||||
<!--
|
||||
The Node authorizer allows a kubelet to perform API operations. This includes:
|
||||
<!--
|
||||
The Node authorizer allows a kubelet to perform API operations. This includes:
|
||||
-->
|
||||
|
||||
读取操作：
|
||||
<!--
|
||||
Read operations:
|
||||
<!--
|
||||
Read operations:
|
||||
-->
|
||||
|
||||
* services
|
||||
* endpoints
|
||||
* nodes
|
||||
* pods
|
||||
* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷
|
||||
* secrets、configmaps、pvcs 以及绑定到 kubelet 节点的与 pod 相关的持久卷
|
||||
|
||||
<!--
|
||||
<!--
|
||||
* services
|
||||
* endpoints
|
||||
* nodes
|
||||
* pods
|
||||
* secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node
|
||||
* secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node
|
||||
-->
|
||||
|
||||
写入操作：
|
||||
<!--
|
||||
Write operations:
|
||||
<!--
|
||||
Write operations:
|
||||
-->
|
||||
|
||||
* 节点和节点状态（启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改自己的节点）
|
||||
* Pod 和 Pod 状态 (启用 `NodeRestriction` 准入插件以限制 kubelet 只能修改绑定到自身的 Pod)
|
||||
* 事件
|
||||
|
||||
<!--
|
||||
<!--
|
||||
* nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node)
|
||||
* pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself)
|
||||
* events
|
||||
* events
|
||||
-->
|
||||
|
||||
鉴权相关操作：
|
||||
<!--
|
||||
Auth-related operations:
|
||||
<!--
|
||||
Auth-related operations:
|
||||
-->
|
||||
|
||||
* 对于基于 TLS 的启动引导过程时使用的 certificationsigningrequests API 的读/写权限
|
||||
* 为委派的身份验证/授权检查创建 tokenreviews 和 subjectaccessreviews 的能力
|
||||
|
||||
<!--
|
||||
<!--
|
||||
* read/write access to the certificationsigningrequests API for TLS bootstrapping
|
||||
* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
|
||||
* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
|
||||
-->
|
||||
|
||||
在将来的版本中，节点鉴权器可能会添加或删除权限，以确保 kubelet 具有正确操作所需的最小权限集。
|
||||
<!--
|
||||
<!--
|
||||
In future releases, the node authorizer may add or remove permissions to ensure kubelets
|
||||
have the minimal set of permissions required to operate correctly.
|
||||
have the minimal set of permissions required to operate correctly.
|
||||
-->
|
||||
|
||||
为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中，用户名为 `system:node:<nodeName>`。
|
||||
上述的组名和用户名格式要与 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
|
||||
<!--
|
||||
In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
|
||||
上述的组名和用户名格式要与 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。
|
||||
<!--
|
||||
In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
|
||||
being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
|
||||
This group and user name format match the identity created for each kubelet as part of
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
|
||||
This group and user name format match the identity created for each kubelet as part of
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
|
||||
-->
|
||||
|
||||
要启用节点授权器，请使用 `--authorization-mode = Node` 启动 apiserver。
|
||||
<!--
|
||||
To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
|
||||
<!--
|
||||
To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
|
||||
-->
|
||||
|
||||
要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
|
||||
<!--
|
||||
要限制 kubelet 具有写入权限的 API 对象，请使用 `--enable-admission-plugins=...,NodeRestriction,...` 启动 apiserver，从而启用 [NodeRestriction](/zh/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) 准入插件。
|
||||
<!--
|
||||
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
|
||||
-->
|
||||
|
||||
## 迁移考虑因素
|
||||
<!--
|
||||
## Migration considerations
|
||||
<!--
|
||||
## Migration considerations
|
||||
-->
|
||||
|
||||
### 在 `system:nodes` 组之外的 Kubelet
|
||||
<!--
|
||||
### Kubelets outside the `system:nodes` group
|
||||
<!--
|
||||
### Kubelets outside the `system:nodes` group
|
||||
-->
|
||||
|
||||
`system:nodes` 组之外的 kubelet 不会被 `Node` 鉴权模式授权，并且需要继续通过当前授权它们的机制来授权。
|
||||
节点准入插件不会限制来自这些 kubelet 的请求。
|
||||
<!--
|
||||
<!--
|
||||
Kubelets outside the `system:nodes` group would not be authorized by the `Node` authorization mode,
|
||||
and would need to continue to be authorized via whatever mechanism currently authorizes them.
|
||||
The node admission plugin would not restrict requests from these kubelets.
|
||||
The node admission plugin would not restrict requests from these kubelets.
|
||||
-->
|
||||
|
||||
### 具有无差别用户名的 Kubelet
|
||||
<!--
|
||||
### Kubelets with undifferentiated usernames
|
||||
<!--
|
||||
### Kubelets with undifferentiated usernames
|
||||
-->
|
||||
|
||||
在一些部署中，kubelet 具有 `system:nodes` 组的凭证，但是无法给出它们所关联的节点的标识，因为它们没有 `system:node:...` 格式的用户名。
|
||||
这些 kubelet 不会被 `Node` 授权模式授权，并且需要继续通过当前授权它们的任何机制来授权。
|
||||
<!--
|
||||
<!--
|
||||
In some deployments, kubelets have credentials that place them in the `system:nodes` group,
|
||||
but do not identify the particular node they are associated with,
|
||||
because they do not have a username in the `system:node:...` format.
|
||||
These kubelets would not be authorized by the `Node` authorization mode,
|
||||
and would need to continue to be authorized via whatever mechanism currently authorizes them.
|
||||
and would need to continue to be authorized via whatever mechanism currently authorizes them.
|
||||
-->
|
||||
|
||||
因为默认的节点标识符实现不会把它当作节点身份标识，`NodeRestriction` 准入插件会忽略来自这些 kubelet 的请求。
|
||||
<!--
|
||||
<!--
|
||||
The `NodeRestriction` admission plugin would ignore requests from these kubelets,
|
||||
since the default node identifier implementation would not consider that a node identity.
|
||||
since the default node identifier implementation would not consider that a node identity.
|
||||
-->
|
||||
|
||||
### 相对于以前使用 RBAC 的版本的更新
|
||||
<!--
|
||||
### Upgrades from previous versions using RBAC
|
||||
<!--
|
||||
### Upgrades from previous versions using RBAC
|
||||
-->
|
||||
|
||||
升级的 1.7 之前的使用 [RBAC](/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
|
||||
<!--
|
||||
升级的 1.7 之前的使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 的集群将继续按原样运行，因为 `system:nodes` 组绑定已经存在。
|
||||
<!--
|
||||
Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
|
||||
-->
|
||||
|
||||
如果集群管理员希望开始使用 `Node` 鉴权器和 `NodeRestriction` 准入插件来限制节点对 API 的访问，这一需求可以通过下列操作来完成且不会影响已部署的应用：
|
||||
<!--
|
||||
<!--
|
||||
If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin
|
||||
to limit node access to the API, that can be done non-disruptively:
|
||||
-->
|
||||
|
|
@ -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` 集群角色绑定
|
||||
<!--
|
||||
<!--
|
||||
1. Enable the `Node` authorization mode (`--authorization-mode=Node,RBAC`) and the `NodeRestriction` admission plugin
|
||||
2. Ensure all kubelets' credentials conform to the group/username requirements
|
||||
3. Audit apiserver logs to ensure the `Node` authorizer is not rejecting requests from kubelets (no persistent `NODE DENY` messages logged)
|
||||
4. Delete the `system:node` cluster role binding
|
||||
4. Delete the `system:node` cluster role binding
|
||||
-->
|
||||
|
||||
### RBAC 节点权限
|
||||
<!--
|
||||
### RBAC Node Permissions
|
||||
<!--
|
||||
### RBAC Node Permissions
|
||||
-->
|
||||
|
||||
在 1.6 版本中，当使用 [RBAC 鉴权模式](/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
|
||||
<!--
|
||||
In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
|
||||
在 1.6 版本中，当使用 [RBAC 鉴权模式](/zh/docs/reference/access-authn-authz/rbac/) 时，`system:nodes` 集群角色会被自动绑定到 `system:node` 组。
|
||||
<!--
|
||||
In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
|
||||
-->
|
||||
|
||||
在 1.7 版本中，不再推荐将 `system:nodes` 组自动绑定到 `system:node` 角色，因为节点鉴权器通过对 secret 和 configmap 访问的额外限制完成了相同的任务。
|
||||
如果同时启用了 `Node` 和 `RBAC` 授权模式，1.7 版本则不会创建 `system:nodes` 组到 `system:node` 角色的自动绑定。
|
||||
<!--
|
||||
<!--
|
||||
In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated
|
||||
because the node authorizer accomplishes the same purpose with the benefit of additional restrictions
|
||||
on secret and configmap access. If the `Node` and `RBAC` authorization modes are both enabled,
|
||||
the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7.
|
||||
the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7.
|
||||
-->
|
||||
|
||||
在 1.8 版本中，绑定将根本不会被创建。
|
||||
<!--
|
||||
In 1.8, the binding will not be created at all.
|
||||
<!--
|
||||
In 1.8, the binding will not be created at all.
|
||||
-->
|
||||
|
||||
使用 RBAC 时，将继续创建 `system:node` 集群角色，以便与将其他用户或组绑定到该角色的部署方法兼容。
|
||||
<!--
|
||||
<!--
|
||||
When using RBAC, the `system:node` cluster role will continue to be created,
|
||||
for compatibility with deployment methods that bind other users or groups to that role.
|
||||
for compatibility with deployment methods that bind other users or groups to that role.
|
||||
-->
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
|||
|
||||
<!--
|
||||
Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all
|
||||
namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read
|
||||
namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read
|
||||
secrets in any namespace.
|
||||
|
||||
```yaml
|
||||
|
|
@ -288,10 +288,10 @@ There are two primary reasons for this restriction:
|
|||
1. A binding to a different role is a fundamentally different binding.
|
||||
Requiring a binding to be deleted/recreated in order to change the `roleRef`
|
||||
ensures the full list of subjects in the binding is intended to be granted
|
||||
the new role (as opposed to enabling accidentally modifying just the roleRef
|
||||
the new role (as opposed to enabling accidentally modifying just the roleRef
|
||||
without verifying all of the existing subjects should be given the new role's permissions).
|
||||
2. Making `roleRef` immutable allows giving `update` permission on an existing binding object
|
||||
to a user, which lets them manage the list of subjects, without being able to change the
|
||||
to a user, which lets them manage the list of subjects, without being able to change the
|
||||
role that is granted to those subjects.
|
||||
|
||||
The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects,
|
||||
|
|
@ -709,7 +709,7 @@ reserved for Kubernetes system use, and so the admin should ensure
|
|||
usernames do not contain this prefix by accident.
|
||||
|
||||
Group information in Kubernetes is currently provided by the Authenticator
|
||||
modules. Groups, like users, are represented as strings, and that string
|
||||
modules. Groups, like users, are represented as strings, and that string
|
||||
has no format requirements, other than that the prefix `system:` is reserved.
|
||||
|
||||
[Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong
|
||||
|
|
@ -721,14 +721,14 @@ to groups with the `system:serviceaccounts:` prefix.
|
|||
主体可以是组，用户或者服务账户。
|
||||
|
||||
用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是
|
||||
邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/docs/reference/access-authn-authz/authentication/)
|
||||
邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的，
|
||||
所以管理员要确保配置的用户名不能出现上述前缀格式。
|
||||
|
||||
用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求，
|
||||
只是不能使用保留的前缀 `system:` 。
|
||||
|
||||
[服务账号](/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
|
||||
[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`，
|
||||
属于前缀为 `system:serviceaccounts:` 的用户组。
|
||||
|
||||
<!--
|
||||
|
|
@ -918,7 +918,7 @@ and updates default cluster role bindings with any missing subjects.
|
|||
This allows the cluster to repair accidental modifications,
|
||||
and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases.
|
||||
|
||||
To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate`
|
||||
To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate`
|
||||
annotation on a default cluster role or rolebinding to `false`.
|
||||
Be aware that missing default permissions and subjects can result in non-functional clusters.
|
||||
|
||||
|
|
@ -1321,7 +1321,7 @@ This is commonly used by add-on API servers for unified authentication and autho
|
|||
The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops.
|
||||
When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account.
|
||||
Corresponding roles exist for each control loop, prefixed with `system:controller:`.
|
||||
If the controller manager is not started with `--use-service-account-credentials`,
|
||||
If the controller manager is not started with `--use-service-account-credentials`,
|
||||
it runs all control loops using its own credential, which must be granted all the relevant roles.
|
||||
These roles include:
|
||||
|
||||
|
|
@ -1355,7 +1355,7 @@ These roles include:
|
|||
-->
|
||||
### 控制器角色 {#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）未启用的状态下依然可以正常工作。
|
||||
|
||||
用户只有在符合下列条件之一的情况下，才能创建/更新角色:
|
||||
|
|
@ -2080,7 +2080,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
|
||||
|
|
@ -2136,5 +2136,3 @@ kubectl create clusterrolebinding permissive-binding \
|
|||
--group=system:serviceaccounts
|
||||
```
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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`。
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ title: Webhook 模式
|
|||
content_type: concept
|
||||
weight: 95
|
||||
---
|
||||
<!--
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
|
|
@ -18,47 +18,47 @@ reviewers:
|
|||
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.
|
||||
<!--
|
||||
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.
|
||||
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.
|
||||
`--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.
|
||||
"clusters" refers to the remote service.
|
||||
-->
|
||||
配置文件的格式使用 [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" 代表着远程服务。
|
||||
|
||||
<!--
|
||||
A configuration example which uses HTTPS client auth:
|
||||
<!--
|
||||
A configuration example which uses HTTPS client auth:
|
||||
-->
|
||||
使用 HTTPS 客户端认证的配置例子：
|
||||
|
||||
<!--
|
||||
<!--
|
||||
```yaml
|
||||
# Kubernetes API version
|
||||
apiVersion: v1
|
||||
|
|
@ -87,7 +87,7 @@ contexts:
|
|||
cluster: name-of-remote-authz-service
|
||||
user: name-of-api-server
|
||||
name: webhook
|
||||
```
|
||||
```
|
||||
-->
|
||||
```yaml
|
||||
# Kubernetes API 版本
|
||||
|
|
@ -119,31 +119,31 @@ contexts:
|
|||
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.
|
||||
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`).
|
||||
enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
|
||||
-->
|
||||
需要注意的是 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`)。
|
||||
|
||||
<!--
|
||||
An example request body:
|
||||
<!--
|
||||
An example request body:
|
||||
-->
|
||||
一个请求内容的例子：
|
||||
|
||||
|
|
@ -167,10 +167,10 @@ An example request body:
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
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:
|
||||
`spec` field is ignored and may be omitted. A permissive response would return:
|
||||
-->
|
||||
期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回:
|
||||
```json
|
||||
|
|
@ -183,17 +183,17 @@ the request and respond to either allow or disallow access. The response body's
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
For disallowing access there are two methods.
|
||||
<!--
|
||||
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 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 将返回:
|
||||
|
||||
|
|
@ -208,11 +208,11 @@ request is forbidden. The webhook would return:
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
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:
|
||||
<!--
|
||||
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 将返回:
|
||||
|
||||
|
|
@ -228,8 +228,8 @@ The webhook would return:
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
Access to non-resource paths are sent as:
|
||||
<!--
|
||||
Access to non-resource paths are sent as:
|
||||
-->
|
||||
对于非资源的路径访问是这么发送的:
|
||||
|
||||
|
|
@ -251,25 +251,21 @@ Access to non-resource paths are sent as:
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
|
||||
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 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.
|
||||
to the REST api.
|
||||
-->
|
||||
非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`,
|
||||
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和
|
||||
`/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/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
|
||||
[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
|
||||
-->
|
||||
更多信息可以参考 authorization.v1beta1 API 对象和[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue