Okay. In this lab, we're going to look at role-based access controls.
The first question is inspect the environment and identify
authorization modes configured on the cluster.
Let's look at the kube-apiserver, so
/etc/kubernetes/manifests/
kube-apiserver.yaml.
Then here we see the options passed to the kube-apiserver.
If you look at the authorization mode, you have node and RBAC.
That's one way of checking that. The other way is to
run docker ps.
No, sorry.
We're going to look at the processes on the control plane, so we're going to do ps
-aux grep or authorization mode.
We know that ultimately,
all containers are running as processes on on the control plane.
We look at the authorization mode configured on the kube-apiserver.
This is basically the kube-apiserver service.
If you look at the authorization mode, it's set to node and RBAC.
These are two ways of finding out the settings passed to the kube-apiserver,
so it's node and RBAC.
How many roles exist in the default namespace?
We're going to do kubectl get roles,
and in the default namespace, there are no roles, so let's select that.
How many roles exist in all namespaces?
You're going to pass into -A to get all namespaces.
Instead of counting, we're going to do no headers.
That prints it without this header, and then we'll do a word count
to count all the lines and we get-
and the answer to that is 12. Let's select 12.
Okay. Now what are the resources the kube-proxy role
in the kube-system namespace is given access to?
Here we have the kube-proxy role,
so let's check that out.
Let's do a kubectl describe
role kube-proxy
-n kube-system.
We see that the resources that this kube-proxy role
has access to is the configmap, so configmaps.
What actions can the kube-proxy role perform on the configmap?
The actions that you can perform for now is just get.
I accidentally clicked that.
Which of the following statements are true?
Kube-proxy role can get details of the configmap object
by the name kube-proxy.
We know that that's true, because kube-proxy role can get
the configmap by the name kube-proxy.
Kube-proxy role can delete the configmap.
It cannot delete the config map, because it doesn't have the delete row up here.
The kube-proxy role can only view and update the configmap object by the name.
Obviously, this is incorrect, but still--
What we need to understand here is that the kube-proxy role can only get
a configmap with the resource name kube-proxy.
That's the correct answer.
Now, which account is the kube-proxy role assigned to?
For that, we need to look at role binding.
Let's look at role bindings
in the kube-system namespace,
and if you look at this, we see that
the kube-proxy role is part of the kube-proxy rolebinding.
Let's look at the kube-proxy rolebinding.
Now with no details, so you have your kubectl describe
rolebindings
kube-proxy in the kube-system namespace.
Here you can see the group
that it has access to for the account that the kube-proxy role is assigned to.
That's system bootstrappers kubeadm default-node-token.
That's the group that it's assigned to.
A dev user is created.
The user' details have been added to the kubeconfig file.
Let's look at the kubeconfig file. Let's do a kubectl config view.
Now we can see that there's a user named dev-user.
Inspect the permissions granted to the user.
Check if the user can list parts in the default namespace.
We can do kubectl get pods,
and we can use the as dev user
option to view as the dev user.
As you can see, it's forbidden.
The user, dev-user cannot list resource pods
in the API group in the default namespace.
The dev user has permissions, does not have permissions.
That's the correct answer.
Now, create the necessary roles and role bindings
required for the dev user to create, list, and delete parts in the default namespace.
First, we have to create the role and role bindings for the dev-user.
We're going to do a kubectl create role. Let's take a look at the help.
We have created role, then the role name, and then the verbs.
The verbs could be passed in comma separated and the resources
that the role has access to.
Let's do that. It's kubectl create a role.
Verbs are going to be list, create, and delete
and resources are going to be pods.
Let's also give it a name.
The name is developer. It's resource, I think.
Let's describe the role.
You can see that the developer role is created with list, create, and delete
access to parts.
Now we have to create a role binding and bind it to the--
Let's do a kubectl create role binding help.
We can create a role binding.
The name is going to be dev user binding,
then the cluster role or
user or end group.
What we want to do is we want to bind the dev user.
[silence]
The role name we're going to use role.
We're going to use kubectl create role binding
and dev user binding,
the role is going to be developer,
and the user is going to be dev-user.
Okay, let's check role binding,
dev-user binding.
We can see user, dev-user
is now associated to develop the role.
Okay. Now, the dev user is trying to get details about the dark blue app
pod in the blue namespace,
but there is an issue so investigate and fix the issue.
Let's do that. As dev user,
I'm going to get details about
the pod dark blue app,
but in the blue namespace or in the blue namespace.
It says, "Dark blue app is forbidden.
User, dev-user cannot get resource pods
in the API group in the namespace globe,"
but it says that we've created the required roles and role binding.
Let's take a look at that.
Let's take the look at the roles in the blue namespace.
We can see that there's a developer role, and then there's
also role bindings in the blue namespace.
There's the dev user binding. Let's take a closer look at those.
Describe role developer
in the blue namespace,
and we see that it has resource pods
and the resource names blue app
that can do a get watch, create, and delete,
but here, as you can see, it's not blue, it's dark blue app.
That's basically the reason that you can't access that.
We're going to edit the role developer in the blue namespace.
What we're going to do is
change this to dark blue app.
Now let's do that again.
We're going to do a get pod dark blue app
in the blue namespace as the user dev user.
We can see that it is now in the running state. That's fixed.
Now, we would like to grant the dev user permissions to create
deployments in the blue namespace.
Let's try that as the dev user,
I want to create a deployment, called engine X,
say with the image engine X, this could be anything.
This is just a test, but in the blue namespace.
When I try to do that it says,
"The user dev user cannot create resource deployments
in API group apps in the default,
in the blue namespace."
What we have to do is we're going to edit the role of developer,
which is used by the dev user in the blue namespace.
What we're going to do is, so this is one rule that allows
a get watch and creates and delete on the dark blue app pod.
What we're going to do is we're going to create a new rule,
so we can just copy this and we're going to paste that.
What we'll do is instead, the API groups for
deployment is apps. We're going to put apps.
We're not going to give any resource names,
because we want to be able to create any resource name here,
we're going to say deployment, and we're going to allow get, watch, create.
After creating, we obviously want to get or watch it or eventually.
Let's just give that.
That's done, let's verify that
role developer in the blue namespace, and we see that we have deployment apps.
We're now able to get, watch, create and delete.
Let's try the command again to create a deployment called engine X
in the Google namespace.
That's still not working. Let's see where that is.
Actually, it should be deployments. Sorry about that.
Let's go and change that.
Let's try that again. That works.
That should be the fix to this. All right. That's the end of this lab.