| system:kube-scheduler |
-system:kube-scheduler user |
-
-允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}
-组件所需要的资源。 |
+
+system:kube-scheduler 用户 |
+
+
+允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}
+组件所需要的资源。
+ |
| system:volume-scheduler |
-system:kube-scheduler user |
-
-允许访问 kube-scheduler 组件所需要的卷资源。 |
+
+system:kube-scheduler 用户 |
+
+
+允许访问 kube-scheduler 组件所需要的卷资源。
+ |
| system:kube-controller-manager |
-system:kube-controller-manager user |
-
-允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}}
+
+ | system:kube-controller-manager 用户 |
+
+
+允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}}
组件所需要的资源。
-各个控制回路所需要的权限在控制器角色 详述。 |
+各个控制回路所需要的权限在控制器角色 详述。
+
| system:node |
-
+
无 |
+
+
+允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。
-
- | 允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。
-
+
你应该使用 Node 鉴权组件 和
NodeRestriction 准入插件
而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权
kubelet 对 API 的访问。
+
+
system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
|
| system:node-proxier |
-system:kube-proxy user |
+
+system:kube-proxy 用户 |
允许访问 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
组件所需要的资源。 |
+
+
| system:auth-delegator |
-
+
无 |
-
-允许将身份认证和鉴权检查操作外包出去。
-这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。 |
+
+
+允许将身份认证和鉴权检查操作外包出去。
+这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
+ |
| system:heapster |
-
+
无 |
-
-为 Heapster 组件（已弃用）定义的角色。 |
+
+
+为 Heapster 组件（已弃用）定义的角色。
+ |
| system:kube-aggregator |
-
+
无 |
为 kube-aggregator 组件定义的角色。 |
| system:kube-dns |
-
-在 kube-system 名字空间中的 kube-dns 服务账号 |
+
+
+在 kube-system 名字空间中的 kube-dns 服务账户 |
-为 kube-dns 组件定义的角色。 |
+为 kube-dns 组件定义的角色。
+ |
| system:kubelet-api-admin |
-
+
无 |
-
-允许 kubelet API 的完全访问权限。 |
+
+
+允许 kubelet API 的完全访问权限。
+ |
| system:node-bootstrapper |
-
+
无 |
-
-允许访问执行
+ |
+
+允许访问执行
kubelet TLS 启动引导
-所需要的资源。 |
+所需要的资源。
+
| system:node-problem-detector |
-
+
无 |
-
-为 node-problem-detector 组件定义的角色。 |
+
+
+为 node-problem-detector 组件定义的角色。
+ |
| system:persistent-volume-provisioner |
-
+
无 |
-
-允许访问大部分
-动态卷驱动
+ |
+
+允许访问大部分
+动态卷驱动
+
所需要的资源。 |
+
+| system:monitoring |
+
+system:monitoring 组 |
+
+
+允许对控制平面监控端点的读取访问（例如：{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+存活和就绪端点（/healthz、/livez、/readyz），
+各个健康检查端点（/healthz/*、/livez/*、/readyz/*）和 /metrics）。
+请注意，各个运行状况检查端点和度量标准端点可能会公开敏感信息。
+ |
+
+
* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 中的权限授予名字空间 "acme"
- 中名为 `myapp` 的服务账号：
+ 中名为 `myapp` 的服务账户：
```shell
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
@@ -1520,7 +1683,7 @@ Grants a Role or ClusterRole within a specific namespace. Examples:
* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp":
-->
* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 对象中的权限授予名字空间
- "myappnamespace" 中名称为 `myapp` 的服务账号：
+ "myappnamespace" 中名称为 `myapp` 的服务账户：
```shell
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
@@ -1556,7 +1719,7 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples:
* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme":
-->
* 在整个集群范围内，将名为 `view` 的 ClusterRole 中定义的权限授予 "acme" 名字空间中
- 名为 "myapp" 的服务账号：
+ 名为 "myapp" 的服务账户：
```shell
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
@@ -1631,15 +1794,15 @@ This allows you to grant particular roles to particular service accounts as need
Fine-grained role bindings provide greater security, but require more effort to administrate.
Broader grants can give unnecessary (and potentially escalating) API access to service accounts, but are easier to administrate.
-->
-## 服务账号权限 {#service-account-permissions}
+## 服务账户权限 {#service-account-permissions}
默认的 RBAC 策略为控制面组件、节点和控制器授予权限。
-但是不会对 `kube-system` 名字空间之外的服务账号授予权限。
+但是不会对 `kube-system` 名字空间之外的服务账户授予权限。
（除了授予所有已认证用户的发现权限）
-这使得你可以根据需要向特定服务账号授予特定权限。
+这使得你可以根据需要向特定服务账户授予特定权限。
细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。
-粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限提升），
+粗粒度的授权可能导致服务账户被授予不必要的 API 访问权限（甚至导致潜在的权限提升），
但更易于管理。
这要求应用在其 Pod 规约中指定 `serviceAccountName`，
- 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。
+ 并额外创建服务账户（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。
- 例如，在名字空间 "my-namespace" 中授予服务账号 "my-sa" 只读权限：
+ 例如，在名字空间 "my-namespace" 中授予服务账户 "my-sa" 只读权限：
```shell
kubectl create rolebinding my-sa-view \
@@ -1672,7 +1835,7 @@ In order from most secure to least secure, the approaches are:
-2. 将角色授予某名字空间中的 "default" 服务账号
+2. 将角色授予某名字空间中的 "default" 服务账户
- 如果某应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。
+ 如果某应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账户。
{{< note >}}
- "default" 服务账号所具有的权限会被授予给名字空间中所有未指定
+ "default" 服务账户所具有的权限会被授予给名字空间中所有未指定
`serviceAccountName` 的 Pod。
{{< /note >}}
- 例如，在名字空间 "my-namespace" 中授予服务账号 "default" 只读权限：
+ 例如，在名字空间 "my-namespace" 中授予服务账户 "default" 只读权限：
```shell
kubectl create rolebinding default-view \
@@ -1712,9 +1875,9 @@ In order from most secure to least secure, the approaches are:
{{< /note >}}
-->
许多[插件组件](/zh/docs/concepts/cluster-administration/addons/) 在 `kube-system`
- 名字空间以 "default" 服务账号运行。
+ 名字空间以 "default" 服务账户运行。
要允许这些插件组件以超级用户权限运行，需要将集群的 `cluster-admin` 权限授予
- `kube-system` 名字空间中的 "default" 服务账号。
+ `kube-system` 名字空间中的 "default" 服务账户。
{{< note >}}
启用这一配置意味着在 `kube-system` 名字空间中包含以超级用户账号来访问 API
@@ -1734,12 +1897,12 @@ In order from most secure to least secure, the approaches are:
For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
-->
-3. 将角色授予名字空间中所有服务账号
+3. 将角色授予名字空间中所有服务账户
- 如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账号，
- 可以将角色授予该名字空间的服务账号组。
+ 如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账户，
+ 可以将角色授予该名字空间的服务账户组。
- 例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账号：
+ 例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账户：
```shell
kubectl create rolebinding serviceaccounts-view \
@@ -1757,9 +1920,9 @@ In order from most secure to least secure, the approaches are:
-->
4. 在集群范围内为所有服务账户授予一个受限角色（不鼓励）
- 如果你不想管理每一个名字空间的权限，你可以向所有的服务账号授予集群范围的角色。
+ 如果你不想管理每一个名字空间的权限，你可以向所有的服务账户授予集群范围的角色。
- 例如，为集群范围的所有服务账号授予跨所有名字空间的只读权限：
+ 例如，为集群范围的所有服务账户授予跨所有名字空间的只读权限：
```shell
@@ -1781,7 +1944,7 @@ In order from most secure to least secure, the approaches are:
-->
5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）
- 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。
+ 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账户。
{{< warning >}}
这样做会允许所有应用都对你的集群拥有完全的访问权限，并将允许所有能够读取
@@ -1814,7 +1977,7 @@ Here are two approaches for managing this transition:
包括授予所有服务帐户全权访问 API 的能力。
默认的 RBAC 策略为控制面组件、节点和控制器等授予有限的权限，但不会为
-`kube-system` 名字空间外的服务账号授权
+`kube-system` 名字空间外的服务账户授权
（除了授予所有认证用户的发现权限之外）。
这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。
@@ -1860,7 +2023,7 @@ You can use that information to determine which roles need to be granted to whic
Once you have [granted roles to service accounts](#service-account-permissions) and workloads
are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer.
-->
-一旦你[将角色授予服务账号](#service-account-permissions) ，工作负载运行时
+一旦你[将角色授予服务账户](#service-account-permissions) ，工作负载运行时
在服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。