A ClusterRole defines a set of Kubernetes RBAC permissions at cluster scope. Unlike a Role, which exists in one namespace, a ClusterRole can be used anywhere in the cluster. Defining permissions does not grant them to anyone; a binding is required. section 3.2.6
The binding determines where a ClusterRole's permissions take effect:
- A RoleBinding grants them only within its namespace. section 3.2.6
- A ClusterRoleBinding grants them cluster-wide. section 3.2.6
Built-in ClusterRoles include admin, view, and cluster-admin. Cluster-admin uses wildcard permissions that cover new resources. Admin generally lists permissions explicitly, so a newly installed component may not be manageable through admin until its permissions are added. Aggregated ClusterRoles provide a way to add those permissions. section 3.2.6 section 3.3.1
Extend admin permissions for a new resource
An admin ClusterRole can select other ClusterRoles labeled `rbac.authorization.k8s.io/aggregate-to-admin: "true"`. A matching ClusterRole can define `get`, `list`, `watch`, `create`, `update`, `patch`, and `delete` permissions for `newresource` in the `newapi` API group, adding those permissions to admin through aggregation. section 3.3.1
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: aggregate-example-admin labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rules: - apiGroups: ["newapi"] resources: ["newresource"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
The manifest shows the matching label and the resource-specific rules on a ClusterRole intended for aggregation into admin. section 3.3.1
