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
@@ -121,10 +121,10 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz
|
||||
HTTP 动词 | request 动词
|
||||
----------|---------------
|
||||
POST | create
|
||||
GET, HEAD | get (单个资源), list (资源集合)
|
||||
GET, HEAD | get (单个资源)，list (资源集合)
|
||||
PUT | update
|
||||
PATCH | patch
|
||||
DELETE | delete (单个资源), deletecollection (资源集合)
|
||||
DELETE | delete (单个资源)，deletecollection (资源集合)
|
||||
|
||||
Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如：
|
||||
|
||||
@@ -144,11 +144,11 @@ Kubernetes有时使用专门的动词检查授权以获得额外的权限。例
|
||||
|
||||
## 授权模块
|
||||
* **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/docs/reference/access-authn-authz/node/).
|
||||
* **ABAC** - 基于属性的访问控制（ABAC) 定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅[ABAC 模式](/docs/reference/access-authn-authz/abac/)。
|
||||
* **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/)。
|
||||
* **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/docs/reference/access-authn-authz/webhook/)。
|
||||
|
||||
<!--
|
||||
#### Checking API Access
|
||||
@@ -197,7 +197,7 @@ field of the returned object is the result of the query.
|
||||
|
||||
* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。
|
||||
* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的命名空间。
|
||||
* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于隐藏/显示操作的UI。
|
||||
* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。
|
||||
|
||||
可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应 “status” 字段是查询的结果。
|
||||
|
||||
@@ -247,11 +247,11 @@ 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 创建和存储策略。
|
||||
@@ -260,7 +260,7 @@ so an earlier module has higher priority to allow or deny a request.
|
||||
* `--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