05 ClusterRole和ClusterRoleBinding

ClusterRole

  集群级别的角色资源ClusterRole资源除了能够管理与Role资源一样的许可权限之外，还可以用于集群级别组件的授权，配置方式及其在rules字段中可内嵌的字段业余Role资源类似。如下示例：

kind: clusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nodes-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch","list"]

• apiGroups: 包含了资源的API组名，支持列表格式指定的多个组，空串””标示核心组。
• resourceNames: 规则应用的目标资源名称列表，可选，缺省时意味着指定资源类型下的所有资源。
• resources: 规则应用的目标资源类型组成的列表,如 “deployments pods daemonsets roles”
• verbs: 可操作列表，必选字段，其值可以有”get list create udate patch watch proxy redirect delete deletecollection”

ClusterRole是集群级别资源，它不属于名称空间，故此其配置不应该使用metadata.namespace字段。

ClusterRoleBinding

  RoleBinding也能够将主题绑定至clusterRole资源之上，但仅能赋予用户访问Rolebinding资源本身所在的名称空间内可由clusterRole赋予的权限。因此，一种常见的做法是集群管理员在集群范围内预先定义好一组访问名称空间级别资源权限的ClusterRole资源，而后在多个名称空间中多次通过RoleBinding引用他们，从而让用户分别具有不通名称空间上的资源的相应访问权限，完成名称空间级别权限的快速授予。但，如果通过ClusterRoleBinding引用这类的ClusterRole，则相应的用户即拥有了在所有名称空间上的权限。
  事实上，所有的非名称空间级别的资源都无法通过RoleBinding绑定至用户并赋予用户相关的权限，这些是属于ClusterRoleBinding的功能。
  另外，出了名称空间及集群级别的资源外，K8s还有这/api /apis /healthz /swaggerapi /version等非资源类型URL，对这些URL的访问也必须实现获得相关的权限。它们也只能定义在ClusterRole当中，且需要ClusterRoleBinding进行授权。不过，对此类资源的读取权限已经由系统默认的名称同为”system:discovery” 的ClusterRole和ClusterRoleBinding两个资源自动设定。

下面的命令显示了 system:discovery 的ClusterRole的相关信息：

[root@kmaster ~]# kubectl get clusterrole system:discovery -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2019-05-09T08:34:43Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "60"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 4b632654-7235-11e9-8c1e-7eef5f257c8f
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /swagger-2.0.0.pb-v1
  - /swagger.json
  - /swaggerapi
  - /swaggerapi/*
  - /version
  - /version/
  verbs:
  - get

下面的命令显示了 system:discovery 的ClusterRoleBinding的相关信息：

[root@kmaster ~]# kubectl get clusterrolebinding system:discovery -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2019-05-09T08:34:44Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "117"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: 4bdde006-7235-11e9-8c1e-7eef5f257c8f
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

  由命令的输出结果可知，它绑定了system:authenticated 和system:unauthenticated 两个组，因此所有用户默认均有权限请求读取这些资源，任何发生API Server的此类端点读取请求都会得到响应。

聚合型 ClusterRole

  k8s 1.9之后的版本，在rules字段中嵌套 “aggregationRule” 字段来整合其他ClusterRole对象的规则，这种类型的ClusterRole权限受控于控制器，他们有所有被标签选择器匹配到的用于聚合的ClusterRole的授权规则合并而成。如下示例：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring
  aggregationRule:
    clusterRoleSelectors:
    - matchLabels:
        rbac.example.com/aggregate-to-monitoring: "true"
    rules: []

下面是一个能够匹配到此聚合性ClusterRole的另一个ClusterRole示例：
```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-tomonitoring: “true”
rules:

• apiGroups: [“”]
  Resources: [“Services”,”endpoints”,”pods”]
  verbs: [“get”,”list”,”watch”]