In this lab,
we'll go over ClusterRoles and ClusterRoleBindings.
For the first few questions of this lab, you would have to inspect
the existing ClusterRoles and ClusterRoleBindings
that have already been created.
Let's go over that.
How many ClusterRoles do you see defined in the cluster?
Let's do a kubectl get clusterroles.
There seems to be a lot.
We have the cluster-admin, a lot of system clusterroles,
and then a few others.
We're going to count this but we're not going to count it manually.
We're going to do no-headers
and then we're going to do a word count,
wc -l.
That's 69, so we're going to select 69.
Now, how many ClusterRoleBindings exist on the system?
Let's do the same thing.
We're going to get clusterrolebindings
and that's 54.
Now, what name namespace is the cluster-admin
clusterrole part of?
If you do a kubectl get clusterroles,
you'll see that they all are here
but as we learned, these are not namespace.
ClusterRoles and ClusterRoleBindings are not namespace.
They're not specific to any namespace.
ClusterRoles are cluster wide and not part of any namespace.
That's the correct answer here.
Now, what user or groups are the cluster-admin role bound to?
The ClusterRoleBinding for the role is with the same name.
Let's take a look at that.
Let's get
clusterrolebindings
and look for cluster-admin.
The cluster-admin role is associated
with the cluster-admin clusterrolebinding.
There are a few others as well
but we're just going to look at this.
Let's describe the clusterrolebindings for cluster-admin.
We see that it's part of the group system:masters.
It's asking the user and groups.
We can also check this out.
Let's check those out.
As you can see, they're associated with a service account.
I'm guessing this is, too, associated with a service account.
We'll just focus on this
and it's associated with the system:masters group,
so this is system:masters.
Now, what level of permission does the cluster-admin role grant?
Let's take a look at that.
kubectl describe clusterrole and cluster-admin.
We see that it's all *, *.* and *,*,*.
* means all access to all resources.
That's basically perform any action on any resource in the cluster.
Now, a new user, michelle, joined the team.
She will be focusing on the nodes in the cluster.
Create the required ClusterRole and ClusterRoleBindings
so she gets access to the node.
Basically, we're looking at kubectl get nodes
but as the user michelle.
As you can see, it says, "Nodes forbidden.
User "michelle" cannot list resource "nodes" in the API group."
It does not give any kind of specifications
on the ClusterRole name or Rolebinding.
Basically, we should be able to create any role and rolebindings as we want.
As long as this command works, this exercise should be good.
If there are no specifications given,
we are free to name things anything as we want.
Let's do a kubectl create clusterrole.
Let's look at the help.
We see kubectl create clusterrole,
then the name,
followed by verb and resource.
This is basically what we want.
We're going to name this
as michelle-role,
and we should have a get, list, and watch,
and the resource is nodes.
Okay.
Now we have to create a ClusterRoleBinding,
clusterrolebinding.
Let's look at the help
and so a ClusterRolebinding binds a ClusterRole to a user.
It's as simple as that.
We're going to
create a ClusterRoleBinding.
We'll call this
michelle-role-binding,
and then we'll have ClusterRole,
which is michelle-role.
That's what we created and the user is michelle.
Let's take a look at that ClusterRole.
Let's first look at the michelle-role
and then let's look at your RoleBinding,
which is michelle-role-binding.
We have get, list, and watch access to nodes.
Then we have the michelle-role associated with michelle user.
Let's try the command again
to test access so kubectl get nodes --as michelle
and that's working.
Okay. Let's check our work.
That's successful.
Now, the next question is
michelle's responsibilities are growing
and now she will be responsible for storage as well.
Create the required ClusterRole and RoleBindings
to allow her access to storage,
get the API groups and resource names from the command kubectl api-resources.
The kubectl api-resources command
is a command that'll help you quickly--
Let's just maximize this so we can see it better.
This command lists all the resources, as well as their short names,
so if you ever want to know
what the short names are for some of these,
this is the command that you should look at.
Deployments have deploy because it has RS.
That's one thing.
It also list the API version
so when you're creating an object,
and if you're not sure about the API version,
this is something that you can look at,
and also if they're namespaced or not.
As we learned the persistentvolumes and persistentvolumeclaims--
I'm sorry.
The ClusterRoleBindings are not namespaced so you should be able to see those here.
ClusterRoles and ClusterRoleBindings are not namespaced
and this is the kind that you would use while creating a definition file.
That's pretty neat.
What we want to do is
we want to create a ClusterRole
to allow michelle access to storageclasses.
We will do a create clusterrole,
the name is storage-admin, so storage-admin,
and the resource,
there are two resources,
persistentvolumes and storageclasses.
First resource is persistentvolumes,
let's get that,
and storageclasses, let's get that.
The verbs are,
let's do list, create, get, and watch.
Those are the four words that are used.
Let's give this a shot.
Okay, so it's created, and let's check it out.
Kubectl describe clusterrole storage-admin.
That's created the role.
I want to look at the role in the yaml format.
We can see that the ClusterRole is created,
name storage-admin.
There are two rules.
It's created two rules, one for each resource.
You have persistentvolumes and then you have storageclass.
That's good.
Now we have to create the ClusterRoleBinding,
which is this.
Kubectl create clusterrole--
The name is michelle-storage-admin.
The user is michelle.
The clusterrole is storage-admin.
Lets take a look.
We can see the ClusterRole that is associated
to a storage-admin and the user is michelle.
Lets do a kubectl --as michelle
and we get storageclasses.
You see that that's working as expected.
That's about it.
Well, that's the end of this lab.