We discussed about roles and role bindings in the previous lecture.
In this lecture we will talk about cluster roles and cluster roles 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 in one of the previous lectures 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 node 01 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 lecture we saw 2 new. Roles and Rolebindings.
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 lecture certificate signing requests we saw earlier and namespace objects themselves are of
course not namespaced.
Note that this is not a comprehensive list of resources to see a full list of namespace and non namespace
resources run the kubectl api-resources command with the namespaced option set. In the previous lecture
we saw how to authorize a user to namespace resources We used Roles and Rolebindings 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 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 this case.
The resources are nodes then create the cluster role.
The next step is to link the user to that cluster role.
For this we create another object called cluster role binding the role binding object links the user
to the role.
We will name it cluster-admin-role-binding. The kind is ClusterRoleBinding. Under subjects we specify
the user details cluster admin user in this case the role ref section is where we provide the details
of the cluster role we created create the role binding using the kubectl create command 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 along 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. We will explore those in the practice tests coming up.
Good luck.