Merge pull request #28264 from tengqm/fix-28249

[zh] Fix and resync RBAC
pull/28950/head
Kubernetes Prow Robot 2021-07-13 00:48:30 -07:00 committed by GitHub
commit 137690980d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions

View File

@ -273,13 +273,13 @@ RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个
```yaml
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "default" 名字空间中的 Secrets
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里仅授权在 "development" 名字空间内的访问权限。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace: development
subjects:
- kind: User
@ -338,15 +338,15 @@ There are two 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 or accidentally modifying only 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
role that is granted to those subjects.
-->
1. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`,
这样可以确保要赋予绑定的所有主体会被授予新的角色(而不是在允许修改
`roleRef` 的情况下导致所有现有主体未经验证即被授予新角色对应的权限)。
这样可以确保要赋予绑定的所有主体会被授予新的角色(而不是在允许或者不小心修改
`roleRef` 的情况下导致所有现有主体未经验证即被授予新角色对应的权限)。
1. 将 `roleRef` 设置为不可以改变,这使得可以为用户授予对现有绑定对象的 `update` 权限,
这样可以让他们管理主体列表,同时不能更改被授予这些主体的角色。
@ -503,7 +503,7 @@ as a cluster administrator, include rules for custom resources, such as those se
or aggregated API servers, to extend the default roles.
For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource
named CronTab, whereas the "view" role can perform just read actions on CronTab resources.
named CronTab, whereas the "view" role can perform only read actions on CronTab resources.
You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server.
-->
默认的[面向用户的角色](#default-roles-and-role-bindings) 使用 ClusterRole 聚合。