-So far we talked about authentication.
We saw how someone can gain access to a cluster.
We saw different ways that someone, a human or a machine,
can get access to the cluster.
Once they gain access, what can they do?
That's what authorization defines.
First of all, why do you need authorization in your cluster?
As an administrator of the cluster, we were able to perform
all sorts of operations in it
such as viewing various objects like pods and nodes and deployments.
Creating or deleting objects such as adding
or deleting pods or even nodes in the cluster.
As an admin, we are able to perform any operation.
Soon, we will have others accessing the cluster
as well such as the other administrators,
developers, testers, or other applications
like monitoring applications or continuous delivery applications
like Jenkins et cetera.
We will be creating accounts for them to access the cluster
by creating usernames and passwords or tokens
or signed [?] certificates for service accounts
as we saw in the previous lectures.
We don't want all of them to have the same level of access as us.
For example, we don't want the developers to have access
to modify our cluster configuration like adding or deleting nodes
or the storage or networking configurations.
We can allow them to view, but not modify.
They could have access to deploying applications.
The same goes with service accounts.
We only want to provide the external application
the minimum level of access to perform its required operations.
When we share our cluster between different organizations
or teams by logically partitioning it using namespaces,
we want to restrict access to the users
to their namespaces alone.
That is what authorization can help you within the cluster.
There are different authorization mechanisms
supported by Kubernetes
such as node authorization, attribute-based authorization,
role-based authorization, and webhook.
Let us go through these now.
We know that the QB-API server is accessed by users like us
for management purposes as well as the Kubelets
on nodes within the cluster for management purposes
within the cluster.
The Kubelet accesses the API server to read information
about services and points, nodes, and pods.
The Kubelet also reports to the QB-API server
with information about the node such as its status.
These requests are handled by a special authorizer
known as the node authorizer.
In the earlier lectures when we discussed about such figures,
we discussed that the Kubelets should be part
of this system nodes group and have a name prefixed
with system node.
Any requests coming from a user with the name system node
and part of the system nodes group is authorized by the node authorizers
and are granted these privileges.
The privileges required for a Kubelet.
That's access within the cluster.
Let's talk about external access to the API.
For instance, a user.
Attribute-based authorization is where you associate
a user or a group of users with a set of permissions.
In this case, we say the dev user can view, create, and delete pods.
You do this by creating a policy file
with a set of policies defined in a JSON format this way.
You pass this file into the API server.
Similarly, we create a policy definition file
for each user or group in this file.
Now, every time you need to add or make a change in the security,
you must edit this policy file manually
and restart the QB-API server.
As such, the attributes-based access control configurations
are difficult to manage.
We will look at role-based access controls next.
Role-based access controls make this much easier.
With role-based access controls, instead of directly associating
a user or a group with a set of permissions,
we define a role.
In this case, for developers.
We create a role with the set of permissions
required for developers.
Then we associate all the developers to that role.
Similarly, create a role for security users
with the right set of permissions required for them.
Then associate the user to that role going forward.
Whenever a change needs to be made to the users access,
we simply modify the role and it reflects
on all developers immediately.
Role-based access control provide a more standard approach
to managing access within the Kubernetes cluster.
We will look at role-based access controls
in much more detail in the next lecture.
For now, let's proceed with the other authorization mechanisms.
Now, what if you want to outsource all the authorization mechanisms.
Say you want to manage authorization externally
and not through the built-in mechanisms
that we just discussed.
For instance, Open Policy agent is a third party tool that helps
with admission control and authorization.
You can have Kubernetes make an API call to the open policy agent
with the information about the user and his access requirements.
Have the Open Policy agent decide if the user should be permitted
or not.
Based on that response, the user is granted access.
Now, there are two more modes in addition to what we just saw.
Always allow and always deny.
As the names states, always allow allows all requests
without performing any authorization checks.
Always deny denies all requests.
Where do you configure these modes?
Which of them are active by default?
Can you have more than one at a time?
How does authorization work if you do have multiple ones configured?
The modes are set using the authorization mode option
on the QB-API server.
If you don't specify this option, it is set to always allow by default.
You may provide a comma-separated list of multiple modes
that you wish to use.
In this case, I want to set it to node RBAC and webhook.
When you have multiple modes configured,
your request is authorized using each one in the order
it is specified.
For example, when a user sends a request,
it's first handled by the node authorizer.
The node authorizer handles only node requests.
It denies the request.
Whenever a module denies a request, it is forwarded to the next one
in the chain.
The role-based access control module performs its checks and grants
the user permission.
Authorization is complete and user is given access
to the requested object.
Every time a module denies a request, it goes to the next one
in the chain.
As soon as a module approves the request,
no more checks are done and the user is granted permission.
Well, that's it for this lecture.
In the upcoming lectures, we will discuss
more about role-based access controls.