Cluster Roles and Role Bindings

Cluster Roles and Role Bindings

In this tutorial, we are going to discuss about cluster roles and cluster roles bindings.

Cluster Roles and Role Bindings

When we talked about roles and role bindings we said that roles and role bindings are namespaced, meaning they are created within namespaces.

If you don’t specify in namespace they’re created in the default namespace and control access within that namespace alone.

Name Scope

In one of the previous tutorials we discussed about name spaces and how it helps in grouping or isolating resources like pods, deployments and services.

But what about other resources like nodes? Can you group or isolate nodes within a namespace? Like can you say node1 is part of the dev namespace? No, those are cluster wide or cluster scoped resources. They cannot be associated to any particular namespace.

So the resources are categorized as either namespaced or cluster scoped.

Now we have seen a lot of namespaced resources throughout this course. Like pods, ReplicaSets, and jobs, deployments, services, secrets, and in the last tutorial we saw 2 new Roles and Role bindings.

These resources are created in the namespace you specify when you create them. If you don’t specify a namespace they are created in the default namespace.

To view them or delete them or update them, you always specify the right namespace.

The cluster scoped resources are those where you don’t specify a namespace when you create them. Like nodes, persistent volumes, persistent ClusterRoles and ClusterRoleBinding that we’re going to look at in this tutorial.

In the previous tutorial we discussed how to authorize a user to namespace resources We used Roles and RolebBndings for that.

But how do we authorize users to cluster wide resources like nodes or persistent volumes that is where you use Cluster Roles and Cluster Role Bindings.

Cluster Roles

Cluster roles are just like roles except they are for a cluster scoped resources.

For example a cluster admin role can be created to provide a cluster administrator permissions to view create or delete nodes in a cluster.

Similarly if storage administrator role can be created to authorize a storage admin to create persistent volumes and claims. Create a cluster all definition file with the kind cluster roll and specify the rules as we did before in previous tutorial.

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRole 
metadata:
   namespace: default
   name: cluster-administrator
rules:
- apiGroups: [""] # "" indicates the core API group  
  resources: ["nodes"]
  verbs: ["get", "list", "create", "delete"]

Now create the cluster role using the kubectl create role command.

$ kubectl create -f cluster-admin-role.yaml
Cluster Role Binding

The next step is to link the user to that cluster role. For this we create another object called Cluster Role Binding. We will name it cluster-admin-role-binding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
  namespace: default
subjects:
- kind: User
  name: cluster-admin 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole 
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

Now create the cluster role binding using the kubectl create command.

$ kubectl create -f cluster-admin-role-binding.yaml

One thing to note before I let you go we said that cluster roles and bindings are used for clusters of resources. But that is not a hard rule you can create a cluster role for namespace resources as well.

When you do that the user will have access to these resources across all name spaces.

Earlier when we created a role to authorize a user to access PODs the user had access to the PODs in a particular namespace alone.

But with cluster rules, when you authorize a user to access the PODs the user gets access to all PODs across the cluster.

Kubernetes creates a number of cluster roles by default when the cluster is first setup.

Cluster Roles and Role Bindings
Scroll to top