Aggregated Role in Kubernetes
k8s 里面授权一般是通过创建一个 role/clusterrole 然后通过 rolebinding/clusterrolebinding 这些和 service account 绑定。
之前有一次需要研究为啥用户拥有我们没有显式赋予的权限的时候,发现了 aggregated roles.
例如一般集群里面都会有一个 view 这个 clusterrole。可以看到这里面集中了很多的权限。
1aggregationRule:
2 clusterRoleSelectors:
3 - matchLabels:
4 rbac.authorization.k8s.io/aggregate-to-view: "true"
5apiVersion: rbac.authorization.k8s.io/v1
6kind: ClusterRole
7metadata:
8 annotations:
9 rbac.authorization.kubernetes.io/autoupdate: "true"
10 labels:
11 kubernetes.io/bootstrapping: rbac-defaults
12 rbac.authorization.k8s.io/aggregate-to-edit: "true"
13 name: view
14rules:
15- apiGroups:
16 - argoproj.io
17 resources:
18 - rollouts开头那个 aggregationRule,会按照那个规则里面定义的 label 来聚合。继续查有那个 label 的 clusterrole,就能看到这些权限来自哪里。
相当于是说,这个类型的 role 的定义其实是来自于其他 role,是动态更新的。这样可以通过创建一些 role 然后做不同聚合的方式来达到某种复用。同时比如你安装某个组件的之后,它可以创建一个这样的 role 来把权限给到 admin 或者 read-only 的用户。解决一些基本的需求。