一个例子 我们想要达到的目的：限制该用户只能查看集群的资源，并且能够查看监控图（monitoring）

role文件

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: aideveloper-role
  namespace: monitoring
rules:
- apiGroups:
  - ""
  resources:
  - pods/proxy
  - services/proxy
  verbs:
  - get
  - list
  - watch

roleBinding文件

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: aideveloper-roleBinding
  namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: aideveloper-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: aideveloper

clusterRoleBinding文件

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: aideveloper-view-roleBinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: aideveloper
	```

接下来需要看怎么把monitoring这个只读角色聚合到view中?

如果我们要实现让一个用户既能查看集群所有资源，又能查看集群的监控信息，那么就需要给某个user做两次roleBinding。那么问题来了：如果我们需要的权限比较复杂，比如有几十种，那么要写几十个roleBinding吗？肯定不会那么蠢。从k8s1.9开始，就有一个rbac的聚合机制——aggregate。  
  

聚合的方法是通过matchLabels（即rbac.example.com/aggregate-to-monitoring: "true"），来匹配所有metadata符合该label的ClusterRole。aggregationRule不需要配置 rules 段，它是由controller收集所有匹配的ClusterRole的rules后填充的。
  
比如：

kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: roleTest001 aggregationRule: clusterRoleSelectors:

  • matchLabels: rbac.authorization.k8s.io/aggregate-to-roletest001: "true" rules: [] # Rules are automatically filled in by the controller manager.
创建新的符合matchLabel的clusterRole，controller会将新的rules添加到aggregationRule。如下会将roleTest002的rules添加到上面的ClusterRoleroleTest001，因此这里的rule是不需要填写的。

kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: roleTest002 labels: rbac.authorization.k8s.io/aggregate-to-roletest001: "true"

These rules will be added to the "monitoring" role.

rules:

  • apiGroups: [""] Resources: ["services", "endpoints", "pods"] verbs: ["get", "list", "watch"]
那么我们现在就可以改良上一篇做的RBAC了——我们只需要把monitoring的权限内容聚合到view中，然后只需要给aideveloper这个user分配view这个role即可。就算后面有100个错综复杂的权限，我们也只需要加标签即可，无需再过多的写roleBinding。
  
首先，我们查看一下view这个role的属性：

kubectl edit clusterrole view aggregationRule: clusterRoleSelectors:

  • matchLabels: rbac.authorization.k8s.io/aggregate-to-view: "true" apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2021-01-06T10:11:00Z" labels: kubernetes.io/bootstrapping: rbac-defaults rbac.authorization.k8s.io/aggregate-to-edit: "true" managedFields:
  • apiVersion: rbac.authorization.k8s.io/v1 fieldsType: FieldsV1 fieldsV1: f:aggregationRule: .: {} f:clusterRoleSelectors: {} f:metadata: f:annotations: .: {} f:rbac.authorization.kubernetes.io/autoupdate: {} f:labels: .: {} f:kubernetes.io/bootstrapping: {} f:rbac.authorization.k8s.io/aggregate-to-edit: {} manager: kube-apiserver operation: Update time: "2021-01-06T10:11:00Z"
  • apiVersion: rbac.authorization.k8s.io/v1 fieldsType: FieldsV1 fieldsV1: f:rules: {} manager: kube-controller-manager operation: Update time: "2021-01-07T05:56:44Z" name: view

我们惊喜的发现，这个view天生可聚合——包含aggregationRule。这里我们看到 rbac.authorization.k8s.io/aggregate-to-view: "true" 这个aggregationRule，因此我们把之前做好的monitoring的role里面，加上 rbac.authorization.k8s.io/aggregate-to-view: "true" 标签即可。

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: aideveloper-role namespace: monitoring labels: rbac.authorization.k8s.io/aggregate-to-view: "true" rules:

  • apiGroups:
    • "" resources:
    • pods/proxy
    • services/proxy verbs:
    • get
    • list
    • watch