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 ports and nodes and deployments, creating or deleting objects such as
adding or deleting parts or even nodes in the cluster.
As an admin, we are able to perform any operation.
But 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', etc..
So we will be creating accounts for them to access the cluster by creating usernames and passwords or
tokens or assigned certificates or service accounts, as we saw in the previous lecture's.
But 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, but they could have access to deploy 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
name spaces, we want to restrict access to the users, to their name spaces alone.
That is what authorization can help you within the cluster.
There are different authorization mechanisms supported by communities such as Noad, authorization,
attribute based authorization, rule-based authorization and Web Hook.
Let us go through this now.
We know that the Cuba server is accessed by users like us for management purposes as well as the Cubans
on note, within the cluster for medicinal purposes, within the cluster, the Cuba that accesses the
server to read information about services and points north and parts to Cuba, and also reports to the
Cuba server with information about the note such as its status.
These requests are handled by a special authorizer known as the node authorizer.
In the early lecture's when we discussed about Certificate's, we discussed that the tubeless should
be part of this system node's group and have a name prefixed with system known.
So any requests coming from a user with the name system node and part of the system nodes group is authorized
by the node authorizer and are granted these privileges the privileges required for a CubeSat so that
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 user can view, create and delete part.
You do this by creating a policy file with a set of policies defined in adjacent 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 server.
As such, the attribute based access control configurations are difficult to manage.
We will look at role based access control to 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 to provide a more standard approach to managing access within the communities
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 authorisation 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 communities make an API call to the open policy agent with the information about the user
and his access requirements and 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 name states always allow allows all requests without performing any authorization checks, always
deny denies all requests.
So 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 configure?
The molds are set using the authorization mode auction on the Cuba server.
If you don't specify this option, it is said to always allow by default, you mean provide a comma
separated list of multiple modes that you wish to use.
In this case, I want to set it to node auerback and web hook.
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 no request.
So 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 grabs the user permission.
Authorization is complete and user is given access to the requested object.
So every time a module denies the request, it goes to the next one in the chain.
And 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 rule-based access
controls.