A Role in Kubernetes is bound within a namespace. A ClusterRole, on the other hand, is cluster-wide. The following is an example of Role, which can perform all operations, including get, watch, list, create, update, delete, and patch, on the deployments, replicasets, and pods resources:

// configuration file for a role named devops-role
# cat 5-2_rbac/5-2_role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: chapter5
  name: devops-role
rules:
- apiGroups: ["", "extensions", "apps"]
  resources:
    - "deployments"
    - "replicasets"
    - "pods"
  verbs: ["*"]

// create the role
# kubectl create -f 5-2_rbac/5-2_role.yaml
role.rbac.authorization.k8s.io/devops-role created

In apiGroups, an empty string [""] indicates the core API group. The API group is part of the RESTful API call. The core indicates the original API call path, such as /api/v1. The newer REST path has the group name and API version in it, such as /apis/$GROUP_NAME/$VERSION. To look up API groups you'd like to use, check out API references at https://kubernetes.io/docs/reference. Under resources, you could add the resources you'd like to grant access to, and under verbs, you could list a set of actions that this role could perform. Let's get into a more advanced example for ClusterRoles, which we used in Chapter 9, Continuous Delivery:

// configuration file for a cluster role
# cat 5-2_rbac/5-2_clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cd-role
rules:
- apiGroups: ["extensions", "apps"]
  resources:
    - deployments
    - replicasets
    - ingresses
  verbs: ["*"]
- apiGroups: [""]
  resources:
    - namespaces
    - events
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
    - pods
    - services
    - secrets
    - replicationcontrollers
    - persistentvolumeclaims
    - jobs
    - cronjobs
  verbs: ["*"]

// create the cluster role
# kubectl create -f 5-2_rbac/5-2_clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/cd-role created

ClusterRole is cluster-wide. Some resources don't belong to any namespace, such as nodes, and can only be controlled by ClusterRole. The namespaces it can access depends on the namespaces field that it associates with ClusterRoleBinding. In the preceding example, we granted the permission to allow this role read and write deployments, replicasets, and ingresses in both extensions and apps groups. In the core API group, we only grant access for namespace and events, as well as all permissions for other resources, such as pods and services.