Roles and ClusterRoles

A Role is a list of rules inside one namespace; each rule names API groups ("" for the core group, apps, batch...), resources (including subresources such as pods/log) and verbs (get, list, watch, create, update, patch, delete). A ClusterRole has the same shape without a namespace, so it can cover cluster-scoped resources or serve as a reusable template:

A Role generated by kubectl, and the built-in user-facing ClusterRolesShell

kubectl create role pod-reader --verb=get,list,watch --resource=pods,pods/log \
  --dry-run=client -o yaml | yq -o json -I0 '.rules'
kubectl get clusterroles -o name | grep -v -e system: -e kindnet -e local-path | head
kubectl get clusterrole view \
  -o jsonpath='{.aggregationRule.clusterRoleSelectors[0].matchLabels}{"\n"}'

Output

[{"apiGroups":[""],"resources":["pods","pods/log"],"verbs":["get","list","watch"]}]
clusterrole.rbac.authorization.k8s.io/admin
clusterrole.rbac.authorization.k8s.io/cluster-admin
clusterrole.rbac.authorization.k8s.io/edit
clusterrole.rbac.authorization.k8s.io/kubeadm:get-nodes
clusterrole.rbac.authorization.k8s.io/view
{"rbac.authorization.k8s.io/aggregate-to-view":"true"}

cluster-admin can do anything, admin and edit manage a namespace's workloads (only admin its roles), and view reads them but not Secrets. view is aggregated from every ClusterRole carrying that label, which is how an add-on's custom resources become readable to viewers without anyone editing view.

MENU