Hello and welcome to this lecture on authentication in this cluster, Kluster, as we have seen already.
The cabinet is closer, consists of multiple nodes, physical or virtual, and various components that
work together.
If users like administrators that access the cluster to perform administrative tasks, the developers
that access the closer to test or deploy applications, we have end users who access the applications
deployed on the cluster and we have third party applications accessing the cluster for integration purposes.
Throughout this section, we will discuss how to secure our cluster by securing the communication between
internal components and securing management access to the cluster through authentication and authorization
mechanisms in this lecture.
Our focus is on securing access to the communities cluster with authentication mechanisms.
So we talked about the different users that may be accessing the cluster security of end users who access
the applications deployed on the cluster is managed by the applications themselves internally.
So we will take them out of our discussion.
Our focus is on users access to the cognitive cluster for administrative purposes.
So we are left with two types of users, humans such as the administrators and developers and robots
such as other processors or services or applications that require access to the cluster.
Cabinet Harris does not manage user accounts natively, it relies on an external source like a file
with user details or certificates or a third party identity service like that to manage these users.
And so you cannot create users in a cabinet as cluster or view the list of users like this.
However, in case of service accounts, companies can manage them.
You can create and manage service accounts using the Cabinet API.
We have a section on service accounts exclusively where we discuss and practice more about service accounts.
For this lecture, we will focus on users in communities, all user access is managed by the API server,
whether you're accessing the cluster through a control tool or the API directly, all of these requests
go through the API server.
The Cube API server authenticates the request before processing it.
So how does the API server authenticate?
There are different authentication mechanisms that can be configured.
You can have a list of usernames and passwords in a static password file or usernames and tokens in
a static token file, or you can authenticate using certificates.
And another option is to connect to third party authentication protocols like that Kerberos, etc..
We will look at some of these next.
Let's start with static password and token files as it is the easiest to understand.
Let's start with the simplest form of authentication, you can create a list of users and their passwords
in a case file and use that as the source for user information.
The file has three columns password, username and user I.D. Within the file name has an option to the
Cube API server.
Remember the civil service and the various options we looked at earlier in this course, that is where
you must specify this option, you must then restart the Cuban server for these options to take effect.
If you set up your cluster using the Keverian to, then you must modify the Cuba space over pod definition
file.
The Cuban yamata will automatically restart the Kubica server once you update this file.
To authenticate using the basic credentials while accessing the API server, specify the user and password
in a command like this.
In The Cafferty File with the user details that we saw, we can optionally have a fourth column with
the group details to assign users to specific groups.
Similarly, instead of a static password file, you can have a static token file here instead of password,
you specify a token pass the token file as an option token or file to the server while authenticating
specified a token as an authorization bearer.
Token to your request like this.
That's it for this lecture.
Remember that this authentication mechanism that stores usernames, passwords and tokens and clear text
in a static file is not a recommended approach as it is insecure.
But I thought this was the easiest way to understand the basics of authentication and communities going
forward.
We will look at other authentication mechanisms.
I also want to point out that if you were trying this out in a cupboard's setup, you must also consider
volume mounts to passing the out.
Final details about these are available in the article that follows.
And remember to set up authorization for the new users.
We will discuss about authorization later in this course in the upcoming lectures, we will discuss
about certificate based authentication and how the various components within this cluster are secured
using certificates.