wd and cc

-- Good good study, day day up!

Aggregated Role in Kubernetes

#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 的用户。解决一些基本的需求。

comments powered by Disqus