Cluster Role
Usage and Concept of Cluster Role
Reference (opens in a new tab)
The concept of cluster role is similar to role, but the difference is that cluster role is not namespaced. It is used to grant permissions to resources across all namespaces. Cluster roles are useful for cluster-wide permissions.
- cluster-scoped resources (like nodes, namespaces, etc.)
- non-resource endpoints (like
/healthz
,/version
, etc.) - namespaced resources (like pods, services, etc.) across all namespaces
- For example, you can create a cluster role to grant access to all pods in all namespaces.
# list all resources under namespace
kubectl api-resources --namespaced=false
# this will help you to get the verb
kubectl api-resources --namespaced=false --sort-by name -o wide
NAME | APIVERSION | KIND |
---|---|---|
componentstatuses | v1 | ComponentStatus |
namespaces | v1 | Namespace |
nodes | v1 | Node |
persistentvolumes | v1 | PersistentVolume |
mutatingwebhookconfigurations | admissionregistration.k8s.io/v1 | MutatingWebhookConfiguration |
validatingadmissionpolicies | admissionregistration.k8s.io/v1 | ValidatingAdmissionPolicy |
validatingadmissionpolicybindings | admissionregistration.k8s.io/v1 | ValidatingAdmissionPolicyBinding |
validatingwebhookconfigurations | admissionregistration.k8s.io/v1 | ValidatingWebhookConfiguration |
customresourcedefinitions | apiextensions.k8s.io/v1 | CustomResourceDefinition |
apiservices | apiregistration.k8s.io/v1 | APIService |
selfsubjectreviews | authentication.k8s.io/v1 | SelfSubjectReview |
tokenreviews | authentication.k8s.io/v1 | TokenReview |
selfsubjectaccessreviews | authorization.k8s.io/v1 | SelfSubjectAccessReview |
selfsubjectrulesreviews | authorization.k8s.io/v1 | SelfSubjectRulesReview |
subjectaccessreviews | authorization.k8s.io/v1 | SubjectAccessReview |
certificatesigningrequests | certificates.k8s.io/v1 | CertificateSigningRequest |
flowschemas | flowcontrol.apiserver.k8s.io/v1 | FlowSchema |
prioritylevelconfigurations | flowcontrol.apiserver.k8s.io/v1 | PriorityLevelConfiguration |
ingressclasses | networking.k8s.io/v1 | IngressClass |
runtimeclasses | node.k8s.io/v1 | RuntimeClass |
clusterrolebindings | rbac.authorization.k8s.io/v1 | ClusterRoleBinding |
clusterroles | rbac.authorization.k8s.io/v1 | ClusterRole |
priorityclasses | scheduling.k8s.io/v1 | PriorityClass |
csidrivers | storage.k8s.io/v1 | CSIDriver |
csinodes | storage.k8s.io/v1 | CSINode |
storageclasses | storage.k8s.io/v1 | StorageClass |
volumeattachments | storage.k8s.io/v1 | VolumeAttachment |
Now, from the above table, we can see that clusterroles and clusterrolebindings are under cluster scope, meaning that they are created within a cluster. So, we no need to specify the namespace while creating them.
Step 1: Create a Cluster Role
You can use the following command to get the verb for the resource.
kubectl api-resources --namespaced=false --sort-by name -o wide
clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: admin-reader
rules:
- apiGroups: [""]
resources: ["nodes"] # use * to allow all resources
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["secrets"] # accept namespaced resources as well
verbs: ["get", "list", "watch"] # use * to allow all verbs
- nonResourceURLs: ["/healthz", "/logs/*"]
verbs: ["get"]
apiGroups
- The API group of the resource. If you are not sure, you can see the above table (API Version).resources: ["secrets"]
- You can create a cluster role to grant access to all secrets in all namespaces. So, the user can access all secrets in all namespaces.
# You cannot create a role with different rules, as they will mix it up
kubectl create clusterrole admin-reader --verb=get,watch,list --resource=nodes
kubectl create clusterrole admin-reader --verb=get,watch,list --resource=secrets
kubectl create clusterrole admin-reader --verb=get --non-resource-url=/logs/*,/healthz
kubectl get clusterroles
Step 2: Create a Cluster Role Binding
Link the role to a user, group or service account.
rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-binding
subjects: # users, groups, or service accounts
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin-reader # cluster role name
kubectl create clusterrolebinding admin-binding --role=admin-reader --group=manager
kubectl get clusterrolebinding