Merge pull request #25892 from howieyuen/rbac

[zh] sync rbac.md
This commit is contained in:
Kubernetes Prow Robot 2021-01-10 18:41:06 -08:00 committed by GitHub
commit f00fd44ad2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 294 additions and 131 deletions

View File

@ -657,7 +657,7 @@ so that authentication produces usernames in the format you want.
RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 *主体Subject*上。
主体可以是组,用户或者
{{< glossary_tooltip text="服务账" term_id="service-account" >}}。
{{< glossary_tooltip text="服务账" term_id="service-account" >}}。
Kubernetes 用字符串来表示用户名。
用户名可以是普通的用户名,像 "alice";或者是邮件风格的名称,如 "bob@example.com"
@ -692,7 +692,7 @@ to groups with the `system:serviceaccounts:` prefix.
与用户名一样,用户组名也用字符串来表示,而且对该字符串没有格式要求,
只是不能使用保留的前缀 `system:`
[服务账](/zh/docs/tasks/configure-pod-container/configure-service-account/)
[服务账](/zh/docs/tasks/configure-pod-container/configure-service-account/)
的用户名前缀为 `system:serviceaccount:`,属于前缀为 `system:serviceaccounts:`
的用户组。
@ -701,8 +701,8 @@ to groups with the `system:serviceaccounts:` prefix.
- `system:serviceaccount:` (singular) is the prefix for service account usernames.
- `system:serviceaccounts:` (plural) is the prefix for service account groups.
-->
- `system:serviceaccount:` (单数)是用于服务账用户名的前缀;
- `system:serviceaccounts:` (复数)是用于服务账组名的前缀。
- `system:serviceaccount:` (单数)是用于服务账用户名的前缀;
- `system:serviceaccounts:` (复数)是用于服务账组名的前缀。
{{< /note >}}
<!--
@ -741,7 +741,7 @@ subjects:
<!--
For the default service account in the "kube-system" namespace:
-->
对于 `kube-system` 名字空间中的默认服务账
对于 `kube-system` 名字空间中的默认服务账
```yaml
subjects:
@ -751,9 +751,9 @@ subjects:
```
<!--
For all service accounts in the "qa" namespace:
For all service accounts in the "qa" group in any namespace:
-->
对于 "qa" 名字空间中所有的服务账号
对于任何名称空间中的 "qa" 组中所有的服务账户
```yaml
subjects:
@ -762,10 +762,23 @@ subjects:
apiGroup: rbac.authorization.k8s.io
```
<!--
For all service accounts in the "dev" group in the "development" namespace:
-->
对于 "dev" 名称空间中 "development" 组中的所有服务帐户:
```yaml
subjects:
- kind: Group
name: system:serviceaccounts:dev
apiGroup: rbac.authorization.k8s.io
namespace: development
```
<!--
For all service accounts in any namespace:
-->
对于在任何名字空间中的服务账号:
对于在任何名字空间中的服务账
```yaml
subjects:
@ -899,51 +912,69 @@ either do not manually edit the role, or disable auto-reconciliation.
{{< /note >}}
<table>
<!-- caption>Kubernetes RBAC API discovery roles</caption -->
<caption>Kubernetes RBAC API 发现角色</caption>
<colgroup><col width="25%"><col width="25%"><col></colgroup>
<caption>
<!--
Kubernetes RBAC API discovery roles
-->
Kubernetes RBAC API 发现角色
</caption>
<colgroup><col width="25%"><col width="25%"><col></colgroup>
<thead>
<tr>
<!--
<th>Default ClusterRole</th>
<th>Default ClusterRoleBinding</th>
<th>Description</th>
</tr>
<tr>
<td><b>system:basic-user</b></td>
<td><b>system:authenticated</b> group</td>
<td>Allows a user read-only access to basic information about themselves. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.</td>
</tr>
<tr>
<td><b>system:discovery</b></td>
<td><b>system:authenticated</b> group</td>
<td>Allows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.</td>
</tr>
<tr>
<td><b>system:public-info-viewer</b></td>
<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
<td>Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.</td>
-->
<th>默认 ClusterRole</th>
<th>默认 ClusterRoleBinding</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td><b>system:basic-user</b></td>
<!--
<td><b>system:authenticated</b> group</td>
-->
<td><b>system:authenticated</b></td>
<td>允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前,这个角色在
默认情况下也绑定在 <tt>system:unauthenticated</tt> 上。</td>
<td>
<!--
Allows a user read-only access to basic information about themselves.
Prior to 1.14, this role was also bound to <tt>system:unauthenticated</tt> by default.
-->
允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前,这个角色在默认情况下也绑定在 <tt>system:unauthenticated</tt> 上。
</td>
</tr>
<tr>
<td><b>system:discovery</b></td>
<!--
<td><b>system:authenticated</b> group</td>
-->
<td><b>system:authenticated</b></td>
<td>允许以只读方式访问 API 发现端点,这些端点用来发现和协商 API 级别。
在 1.14 版本之前,这个角色在默认情况下绑定在 <tt>system:unauthenticated</tt> 上。</td>
<td>
<!--
Allows read-only access to API discovery endpoints needed to discover and negotiate an API level.
Prior to 1.14, this role was also bound to <tt>system:unauthenticated</tt> by default.
-->
允许以只读方式访问 API 发现端点,这些端点用来发现和协商 API 级别。
在 1.14 版本之前,这个角色在默认情况下绑定在 <tt>system:unauthenticated</tt> 上。
</td>
</tr>
<tr>
<td><b>system:public-info-viewer</b></td>
<!--
<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
-->
<td><b>system:authenticated</b><b>system:unauthenticated</b></td>
<td>允许对集群的非敏感信息进行只读访问,它是在 1.14 版本中引入的。</td>
<td>
<!--
Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
-->
允许对集群的非敏感信息进行只读访问,它是在 1.14 版本中引入的。
</td>
</tr>
</tbody>
</table>
<!--
@ -979,74 +1010,101 @@ metadata:
<table>
<colgroup><col width="25%"><col width="25%"><col></colgroup>
<thead>
<tr>
<!--
<th>Default ClusterRole</th>
<th>Default ClusterRoleBinding</th>
<th>Description</th>
</tr>
-->
<th>默认 ClusterRole</th>
<th>默认 ClusterRoleBinding</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td><b>cluster-admin</b></td>
<!--td><b>system:masters</b> group</td -->
<!--
<td><b>system:masters</b> group</td>
-->
<td><b>system:masters</b></td>
<!-- td>Allows super-user access to perform any action on any resource.
<td>
<!--
Allows super-user access to perform any action on any resource.
When used in a <b>ClusterRoleBinding</b>, it gives full control over every resource in the cluster and in all namespaces.
When used in a <b>RoleBinding</b>, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.</td-->
<td>允许超级用户在平台上的任何资源上执行所有操作。
When used in a <b>RoleBinding</b>, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.
-->
允许超级用户在平台上的任何资源上执行所有操作。
当在 <b>ClusterRoleBinding</b> 中使用时,可以授权对集群中以及所有名字空间中的全部资源进行完全控制。
当在 <b>RoleBinding</b> 中使用时,可以授权控制 RoleBinding 所在名字空间中的所有资源,包括名字空间本身。</td>
当在 <b>RoleBinding</b> 中使用时,可以授权控制 RoleBinding 所在名字空间中的所有资源,包括名字空间本身。
</td>
</tr>
<tr>
<td><b>admin</b></td>
<!-- td>None</td --->
<!--
<td>None</td>
--->
<td></td>
<!-- td>Allows admin access, intended to be granted within a namespace using a <b>RoleBinding</b>.
<td>
<!--
Allows admin access, intended to be granted within a namespace using a <b>RoleBinding</b>.
If used in a <b>RoleBinding</b>, allows read/write access to most resources in a namespace,
including the ability to create roles and rolebindings within the namespace.
It does not allow write access to resource quota or to the namespace itself.</td -->
<td>允许管理员访问权限,旨在使用 <b>RoleBinding</b> 在名字空间内执行授权。
It does not allow write access to resource quota or to the namespace itself.
-->
允许管理员访问权限,旨在使用 <b>RoleBinding</b> 在名字空间内执行授权。
如果在 <b>RoleBinding</b> 中使用,则可授予对名字空间中的大多数资源的读/写权限,
包括创建角色和角色绑定的能力。
但是它不允许对资源配额或者名字空间本身进行写操作。</td>
但是它不允许对资源配额或者名字空间本身进行写操作。
</td>
</tr>
<tr>
<td><b>edit</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows read/write access to most objects in a namespace.
<td>
<!--
Allows read/write access to most objects in a namespace.
This role does not allow viewing or modifying roles or role bindings.
However, this role allows accessing Secrets and running Pods as any ServiceAccount in
the namespace, so it can be used to gain the API access levels of any ServiceAccount in
the namespace.</td -->
<td>允许对名字空间的大多数对象进行读/写操作。
the namespace.
-->
允许对名字空间的大多数对象进行读/写操作。
它不允许查看或者修改角色或者角色绑定。
不过,此角色可以访问 Secret以名字空间中任何 ServiceAccount 的身份运行 Pods
所以可以用来了解名字空间内所有服务账的 API 访问级别。
所以可以用来了解名字空间内所有服务账的 API 访问级别。
</td>
</tr>
<tr>
<td><b>view</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows read-only access to see most objects in a namespace.
<td>
<!--
Allows read-only access to see most objects in a namespace.
It does not allow viewing roles or rolebindings.
-->
允许对名字空间的大多数对象有只读权限。
它不允许查看角色或角色绑定。
<!--
This role does not allow viewing Secrets, since reading
the contents of Secrets enables access to ServiceAccount credentials
in the namespace, which would allow API access as any ServiceAccount
in the namespace (a form of privilege escalation).</td -->
<td>允许对名字空间的大多数对象有只读权限。
它不允许查看角色或角色绑定。
in the namespace (a form of privilege escalation).
-->
此角色不允许查看 Secrets因为读取 Secret 的内容意味着可以访问名字空间中
ServiceAccount 的凭据信息,进而允许利用名字空间中任何 ServiceAccount 的
身份访问 API这是一种特权提升</td>
身份访问 API这是一种特权提升
</td>
</tr>
</tbody>
</table>
<!--
@ -1056,62 +1114,99 @@ ServiceAccount 的凭据信息,进而允许利用名字空间中任何 Service
<table>
<colgroup><col width="25%"><col width="25%"><col></colgroup>
<thead>
<tr>
<!--
<th>Default ClusterRole</th>
<th>Default ClusterRoleBinding</th>
<th>Description</th>
-->
<th>默认 ClusterRole</th>
<th>默认 ClusterRoleBinding</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td><b>system:kube-scheduler</b></td>
<td><b>system:kube-scheduler</b> user</td>
<!-- td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.</td -->
<td>允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}
组件所需要的资源。</td>
<!--
<td><b>system:kube-scheduler</b> user</td>
-->
<td><b>system:kube-scheduler</b> 用户</td>
<td>
<!--
Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
-->
允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}
组件所需要的资源。
</td>
</tr>
<tr>
<td><b>system:volume-scheduler</b></td>
<td><b>system:kube-scheduler</b> user</td>
<!-- td>Allows access to the volume resources required by the kube-scheduler component.</td -->
<td>允许访问 kube-scheduler 组件所需要的卷资源。</td>
<!--
<td><b>system:kube-scheduler</b> user</td>
-->
<td><b>system:kube-scheduler</b> 用户</td>
<td>
<!--
Allows access to the volume resources required by the kube-scheduler component.
-->
允许访问 kube-scheduler 组件所需要的卷资源。
</td>
</tr>
<tr>
<td><b>system:kube-controller-manager</b></td>
<td><b>system:kube-controller-manager</b> user</td>
<!-- td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component.
The permissions required by individual controllers are detailed in the <a href="#controller-roles">controller roles</a>.</td-->
<td>允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}}
<!--
<td><b>system:kube-controller-manager</b> user</td>
-->
<td><b>system:kube-controller-manager</b> 用户</td>
<td>
<!--
Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component.
The permissions required by individual controllers are detailed in the <a href="#controller-roles">controller roles</a>.
-->
允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}}
组件所需要的资源。
各个控制回路所需要的权限在<a href="#controller-roles">控制器角色</a> 详述。</td>
各个控制回路所需要的权限在<a href="#controller-roles">控制器角色</a> 详述。
</td>
</tr>
<tr>
<td><b>system:node</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<td>
<!--
Allows access to resources required by the kubelet, <b>including read access to all secrets, and write access to all pod status objects</b>.
-->
允许访问 kubelet 所需要的资源,<b>包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。</b>
<!-- td>Allows access to resources required by the kubelet, <b>including read access to all secrets, and write access to all pod status objects</b>.
You should use the <a href="/docs/reference/access-authn-authz/node/">Node authorizer</a> and <a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> instead of the <tt>system:node</tt> role, and allow granting API access to kubelets based on the Pods scheduled to run on them.
The <tt>system:node</tt> role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
</td -->
<td>允许访问 kubelet 所需要的资源,<b>包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。</b>
<!--
You should use the <a href="/docs/reference/access-authn-authz/node/">Node authorizer</a> and
<a href="/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction admission plugin</a>
instead of the <tt>system:node</tt> role, and allow granting API access to kubelets based on the Pods scheduled to run on them.
-->
你应该使用 <a href="/zh/docs/reference/access-authn-authz/node/">Node 鉴权组件</a>
<a href="/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction">NodeRestriction 准入插件</a>
而不是 <tt>system:node</tt> 角色。同时基于 kubelet 上调度执行的 Pod 来授权
kubelet 对 API 的访问。
<!--
The <tt>system:node</tt> role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
-->
<tt>system:node</tt> 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。
</td>
</tr>
<tr>
<td><b>system:node-proxier</b></td>
<td><b>system:kube-proxy</b> user</td>
<!-- <td><b>system:kube-proxy</b> user</td> -->
<td><b>system:kube-proxy</b> 用户</td>
<!-- td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.</td-->
<td>允许访问 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
组件所需要的资源。</td>
</tr>
</tbody>
</table>
<!--
@ -1121,77 +1216,145 @@ kubelet 对 API 的访问。
<table>
<colgroup><col width="25%"><col width="25%"><col></colgroup>
<thead>
<tr>
<!-- th>Default ClusterRole</th>
<!--
<th>Default ClusterRole</th>
<th>Default ClusterRoleBinding</th>
<th>Description</th -->
<th>Description</th>
-->
<th>默认 ClusterRole</th>
<th>默认 ClusterRoleBinding</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td><b>system:auth-delegator</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows delegated authentication and authorization checks.
This is commonly used by add-on API servers for unified authentication and authorization.</td -->
<td>允许将身份认证和鉴权检查操作外包出去。
这种角色通常用在插件式 API 服务器上,以实现统一的身份认证和鉴权。</td>
<td>
<!--
Allows delegated authentication and authorization checks.
This is commonly used by add-on API servers for unified authentication and authorization.
-->
允许将身份认证和鉴权检查操作外包出去。
这种角色通常用在插件式 API 服务器上,以实现统一的身份认证和鉴权。
</td>
</tr>
<tr>
<td><b>system:heapster</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Role for the <a href="https://github.com/kubernetes/heapster">Heapster</a> component (deprecated).</td -->
<td><a href="https://github.com/kubernetes/heapster">Heapster</a> 组件(已弃用)定义的角色。</td>
<td>
<!--
Role for the <a href="https://github.com/kubernetes/heapster">Heapster</a> component (deprecated).
-->
<a href="https://github.com/kubernetes/heapster">Heapster</a> 组件(已弃用)定义的角色。
</td>
</tr>
<tr>
<td><b>system:kube-aggregator</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Role for the <a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a> component.</td -->
<td><a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a> 组件定义的角色。</td>
</tr>
<tr>
<td><b>system:kube-dns</b></td>
<!-- td><b>kube-dns</b> service account in the <b>kube-system</b> namespace</td -->
<td><b>kube-system</b> 名字空间中的 <b>kube-dns</b> 服务账号</td>
<td>
<!--
<b>kube-dns</b> service account in the <b>kube-system</b> namespace</td
-->
<b>kube-system</b> 名字空间中的 <b>kube-dns</b> 服务账户</td>
<!-- td>Role for the <a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> component.</td -->
<td><a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> 组件定义的角色。</td>
<td><a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> 组件定义的角色。
</td>
</tr>
<tr>
<td><b>system:kubelet-api-admin</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows full access to the kubelet API.</td -->
<td>允许 kubelet API 的完全访问权限。</td>
<td>
<!--
Allows full access to the kubelet API.
-->
允许 kubelet API 的完全访问权限。
</td>
</tr>
<tr>
<td><b>system:node-bootstrapper</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows access to the resources required to perform
<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">Kubelet TLS bootstrapping</a>.</td -->
<td>允许访问执行
<td>
<!--
Allows access to the resources required to perform
<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">Kubelet TLS bootstrapping</a>.
-->
允许访问执行
<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">kubelet TLS 启动引导</a>
所需要的资源。</td>
所需要的资源。
</td>
</tr>
<tr>
<td><b>system:node-problem-detector</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> component.</td -->
<td><a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> 组件定义的角色。</td>
<td>
<!--
Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> component.
-->
<a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> 组件定义的角色。
</td>
</tr>
<tr>
<td><b>system:persistent-volume-provisioner</b></td>
<!-- td>None</td -->
<!--
<td>None</td>
-->
<td></td>
<!-- td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td -->
<td>允许访问大部分
<a href="/docs/concepts/storage/persistent-volumes/#provisioner">动态卷驱动</a>
<td>
<!--
Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.
-->
允许访问大部分
<a href="/docs/concepts/storage/persistent-volumes/#provisioner">动态卷驱动
</a>
所需要的资源。</td>
</tr>
<tr>
<td><b>system:monitoring</b></td>
<!--
<td><b>system:monitoring</b> group</td>
-->
<td><b>system:monitoring</b></td>
<td>
<!--
Allows read access to control-plane monitoring endpoints
(i.e. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness endpoints
(<tt>/healthz</tt>, <tt>/livez</tt>, <tt>/readyz</tt>), the individual health-check endpoints
(<tt>/healthz/*</tt>, <tt>/livez/*</tt>, <tt>/readyz/*</tt>), and <tt>/metrics</tt>).
Note that individual health check endpoints and the metric endpoint may expose sensitive information.
-->
允许对控制平面监控端点的读取访问(例如:{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
存活和就绪端点(<tt>/healthz</tt><tt>/livez</tt><tt>/readyz</tt>
各个健康检查端点(<tt>/healthz/*</tt><tt>/livez/*</tt><tt>/readyz/*</tt>)和 <tt>/metrics</tt>)。
请注意,各个运行状况检查端点和度量标准端点可能会公开敏感信息。
</td>
</tr>
</tbody>
</table>
<!--
@ -1212,7 +1375,7 @@ These roles include:
Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}}
运行内建于 Kubernetes 控制面的{{< glossary_tooltip term_id="controller" text="控制器" >}}。
当使用 `--use-service-account-credentials` 参数启动时, kube-controller-manager
使用单独的服务账来启动每个控制器。
使用单独的服务账来启动每个控制器。
每个内置控制器都有相应的、前缀为 `system:controller:` 的角色。
如果控制管理器启动时未设置 `--use-service-account-credentials`
它使用自己的身份凭据来运行所有的控制器,该身份必须被授予所有相关的角色。
@ -1510,7 +1673,7 @@ Grants a Role or ClusterRole within a specific namespace. Examples:
* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp":
-->
* 在名字空间 "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 访问权限(甚至导致潜在的权限提升),
但更易于管理。
<!--
@ -1658,9 +1821,9 @@ In order from most secure to least secure, the approaches are:
For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
-->
这要求应用在其 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. Grant a role to the "default" service account in a namespace
-->
2. 将角色授予某名字空间中的 "default" 服务账
2. 将角色授予某名字空间中的 "default" 服务账
<!--
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
@ -1684,14 +1847,14 @@ In order from most secure to least secure, the approaches are:
For example, grant read-only permission within "my-namespace" to the "default" service account:
-->
如果某应用没有指定 `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 鉴权器。
<!--