zh-trans: update docs/reference/access-authn-authz/authorization.md (#13180)
This commit is contained in:
SataQiu
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
7ec7d7b628
commit
1d8ca9fcd0
@@ -28,12 +28,12 @@ that Kubernetes authorization works with existing organization-wide or
|
||||
cloud-provider-wide access control systems which may handle other APIs besides
|
||||
the Kubernetes API. -->
|
||||
|
||||
在Kubernetes中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
|
||||
在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
|
||||
请参阅 [访问控制概述](/docs/reference/access-authn-authz/controlling-access/).
|
||||
|
||||
Kubernetes期望REST API请求中常见的属性。
|
||||
这意味着Kubernetes授权适用于现有的组织范围或云提供商范围的访问控制系统，
|
||||
除了Kubernetes API之外，它还可以处理其他API。
|
||||
Kubernetes 期望 REST API 请求中常见的属性。
|
||||
这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统，
|
||||
除了 Kubernetes API 之外，它还可以处理其他 API。
|
||||
|
||||
<!-- ## Determine Whether a Request is Allowed or Denied
|
||||
Kubernetes authorizes API requests using the API server. It evaluates all of the
|
||||
@@ -52,7 +52,7 @@ the request, then the request is denied. A deny returns an HTTP status code 403.
|
||||
|
||||
## 确定是允许还是拒绝请求
|
||||
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。
|
||||
一个API请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。
|
||||
一个 API 请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。
|
||||
|
||||
（尽管 Kubernetes 使用 API 服务器，但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。）
|
||||
|
||||
@@ -78,19 +78,19 @@ Kubernetes reviews only the following API request attributes:
|
||||
-->
|
||||
|
||||
## 审查您的请求属性
|
||||
Kubernetes仅审查以下API请求属性：
|
||||
Kubernetes 仅审查以下 API 请求属性：
|
||||
|
||||
* **user** - 身份验证期间提供的`user`字符串。
|
||||
* **user** - 身份验证期间提供的 `user` 字符串。
|
||||
* **group** - 经过身份验证的用户所属的组名列表。
|
||||
* **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)。
|
||||
* **HTTP request verb** - HTTP 动词`get`，`post`，`put`和`delete`用于非资源请求。
|
||||
* **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用`get`，`update`，`patch`和`delete`动词的资源请求，您必须提供资源名称。
|
||||
* **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)。
|
||||
* **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 组](/docs/concepts/overview/kubernetes-api/)。
|
||||
|
||||
<!--
|
||||
## Determine the Request Verb
|
||||
@@ -116,21 +116,21 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz
|
||||
|
||||
## 确定请求动词
|
||||
|
||||
要确定资源API端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用：
|
||||
要确定资源 API 端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用：
|
||||
|
||||
HTTP 动词 | request 动词
|
||||
----------|---------------
|
||||
POST | create
|
||||
GET, HEAD | get (单个资源), list (资源集合)
|
||||
GET, HEAD | get (单个资源)，list (资源集合)
|
||||
PUT | update
|
||||
PATCH | patch
|
||||
DELETE | delete (单个资源), deletecollection (资源集合)
|
||||
DELETE | delete (单个资源)，deletecollection (资源集合)
|
||||
|
||||
Kubernetes有时使用专门的动词检查授权以获得额外的权限。例如：
|
||||
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 安全策略](/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`。
|
||||
|
||||
<!--
|
||||
## Authorization Modules
|
||||
@@ -144,11 +144,11 @@ 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/)。
|
||||
* 当指定的RBAC（基于角色的访问控制）使用`rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
|
||||
* 要启用RBAC，请使用`--authorization-mode = RBAC`启动 apiserver 。
|
||||
* **Webhook** - WebHook 是一个 HTTP 回调: 发生某些事情时调用的 HTTP POST;通过 HTTP POST 进行简单的事件通知。实现 WebHooks 的 Web 应用程序会在发生某些事情时将消息发布到URL。要了解有关使用 Webhook 模式的更多信息，请参阅[Webhook 模式](/docs/reference/access-authn-authz/webhook/)。
|
||||
* **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/docs/reference/access-authn-authz/abac/)。
|
||||
* **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/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/)。
|
||||
|
||||
<!--
|
||||
#### Checking API Access
|
||||
@@ -158,10 +158,10 @@ The command uses the `SelfSubjectAccessReview` API to determine if the current u
|
||||
a given action, and works regardless of the authorization mode used.
|
||||
-->
|
||||
|
||||
#### 检查API访问
|
||||
#### 检查 API 访问
|
||||
|
||||
`kubectl`提供`auth can-i`子命令，用于快速查询 API 授权层。
|
||||
该命令使用`SelfSubjectAccessReview` API来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。
|
||||
`kubectl` 提供 `auth can-i` 子命令，用于快速查询 API 授权层。
|
||||
该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。
|
||||
|
||||
```bash
|
||||
$ kubectl auth can-i create deployments --namespace dev
|
||||
@@ -192,14 +192,14 @@ These APIs can be queried by creating normal Kubernetes resources, where the res
|
||||
field of the returned object is the result of the query.
|
||||
-->
|
||||
|
||||
`SelfSubjectAccessReview`是`authorization.k8s.io` API组的一部分，它将 API 服务器授权公开给外部服务。
|
||||
`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分，它将 API 服务器授权公开给外部服务。
|
||||
该组中的其他资源包括：
|
||||
|
||||
* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给API服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的API的访问权限。
|
||||
* `LocalSubjectAccessReview` - 与`SubjectAccessReview`类似，但仅限于特定的命名空间。
|
||||
* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于隐藏/显示操作的UI。
|
||||
* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。
|
||||
* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的命名空间。
|
||||
* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。
|
||||
|
||||
可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应“status”字段是查询的结果。
|
||||
可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应 “status” 字段是查询的结果。
|
||||
|
||||
```bash
|
||||
$ kubectl create -f - -o yaml << EOF
|
||||
@@ -247,20 +247,20 @@ You can choose more than one authorization module. Modules are checked in order
|
||||
so an earlier module has higher priority to allow or deny a request.
|
||||
-->
|
||||
|
||||
## 为您的授权模块使用标志
|
||||
## 为您的授权模块应用参数
|
||||
|
||||
您必须在策略中包含一个标志，以指明您的策略包含哪个授权模块：
|
||||
您必须在策略中包含一个参数标志，以指明您的策略包含哪个授权模块：
|
||||
|
||||
可以使用以下标志：
|
||||
可以使用以下参数：
|
||||
|
||||
* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。
|
||||
* `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。
|
||||
* `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程REST端点管理授权。
|
||||
* `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的API请求。
|
||||
* `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程 REST 端点管理授权。
|
||||
* `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的 API 请求。
|
||||
* `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。
|
||||
* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。
|
||||
|
||||
您可以选择多个授权模块。按顺序检查模块，以便较早的模块具有更高的优先级来允许或拒绝请求。
|
||||
您可以选择多个授权模块。模块按顺序检查，以便较早的模块具有更高的优先级来允许或拒绝请求。
|
||||
|
||||
<!--
|
||||
## Privilege escalation via pod creation
|
||||
@@ -271,11 +271,11 @@ access their privileges within that namespace. They can create pods that access
|
||||
secrets the user cannot themselves read, or that run under a service account
|
||||
with different/greater permissions.
|
||||
-->
|
||||
## 通过pod创建权限升级
|
||||
## 通过 Pod 创建升级权限
|
||||
|
||||
能够在命名空间中创建 pod 的用户可能会升级其在该命名空间内的权限。
|
||||
他们可以创建在该命名空间内访问其权限的 pod 。
|
||||
他们可以创建用户无法自己读取 secret 的 pod ，或者在具有不同/更高权限的服务帐户下运行的 pod 。
|
||||
能够在命名空间中创建 Pod 的用户可能会升级其在该命名空间内的权限。
|
||||
他们可以创建在该命名空间内访问其权限的 Pod 。
|
||||
他们可以创建用户无法自己读取 secret 的 Pod ，或者在具有不同/更高权限的服务帐户下运行的 Pod 。
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
@@ -286,9 +286,9 @@ maps in the namespace; and impersonate any service account in the namespace and
|
||||
take any action the account could take. This applies regardless of authorization
|
||||
mode.
|
||||
-->
|
||||
**注意：** 系统管理员在授予对 pod 创建的访问权限时要小心。
|
||||
授予在命名空间中创建 pod（或创建pod的控制器）的权限的用户可以：
|
||||
读取命名空间中的所有秘密;读取命名空间中的所有配置映射;
|
||||
**注意：** 系统管理员在授予对 Pod 创建的访问权限时要小心。
|
||||
授予在命名空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以：
|
||||
读取命名空间中的所有 secret；读取命名空间中的所有 ConfigMap；
|
||||
并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。
|
||||
无论采用何种授权方式，这都适用。
|
||||
{{< /caution >}}
|
||||
@@ -299,6 +299,6 @@ 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 的访问](/docs/reference/access-authn-authz/controlling-access/)。
|
||||
* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/docs/reference/access-authn-authz/admission-controllers/)。
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user