1 00:00:00,390 --> 00:00:06,660 Hello and welcome to this lecture on authentication in this cluster, Kluster, as we have seen already. 2 00:00:06,810 --> 00:00:12,780 The cabinet is closer, consists of multiple nodes, physical or virtual, and various components that 3 00:00:12,780 --> 00:00:13,500 work together. 4 00:00:14,040 --> 00:00:20,070 If users like administrators that access the cluster to perform administrative tasks, the developers 5 00:00:20,070 --> 00:00:26,220 that access the closer to test or deploy applications, we have end users who access the applications 6 00:00:26,220 --> 00:00:32,360 deployed on the cluster and we have third party applications accessing the cluster for integration purposes. 7 00:00:33,330 --> 00:00:40,020 Throughout this section, we will discuss how to secure our cluster by securing the communication between 8 00:00:40,020 --> 00:00:46,500 internal components and securing management access to the cluster through authentication and authorization 9 00:00:46,500 --> 00:00:48,480 mechanisms in this lecture. 10 00:00:48,840 --> 00:00:54,810 Our focus is on securing access to the communities cluster with authentication mechanisms. 11 00:00:56,150 --> 00:01:03,410 So we talked about the different users that may be accessing the cluster security of end users who access 12 00:01:03,410 --> 00:01:09,230 the applications deployed on the cluster is managed by the applications themselves internally. 13 00:01:10,180 --> 00:01:12,280 So we will take them out of our discussion. 14 00:01:13,150 --> 00:01:19,380 Our focus is on users access to the cognitive cluster for administrative purposes. 15 00:01:19,900 --> 00:01:26,860 So we are left with two types of users, humans such as the administrators and developers and robots 16 00:01:26,860 --> 00:01:32,860 such as other processors or services or applications that require access to the cluster. 17 00:01:33,930 --> 00:01:40,590 Cabinet Harris does not manage user accounts natively, it relies on an external source like a file 18 00:01:40,590 --> 00:01:47,670 with user details or certificates or a third party identity service like that to manage these users. 19 00:01:47,820 --> 00:01:53,520 And so you cannot create users in a cabinet as cluster or view the list of users like this. 20 00:01:54,300 --> 00:01:58,640 However, in case of service accounts, companies can manage them. 21 00:01:58,950 --> 00:02:02,770 You can create and manage service accounts using the Cabinet API. 22 00:02:03,300 --> 00:02:09,570 We have a section on service accounts exclusively where we discuss and practice more about service accounts. 23 00:02:11,120 --> 00:02:18,550 For this lecture, we will focus on users in communities, all user access is managed by the API server, 24 00:02:19,040 --> 00:02:25,790 whether you're accessing the cluster through a control tool or the API directly, all of these requests 25 00:02:25,910 --> 00:02:27,800 go through the API server. 26 00:02:28,280 --> 00:02:33,200 The Cube API server authenticates the request before processing it. 27 00:02:34,100 --> 00:02:36,540 So how does the API server authenticate? 28 00:02:37,070 --> 00:02:40,410 There are different authentication mechanisms that can be configured. 29 00:02:41,030 --> 00:02:48,230 You can have a list of usernames and passwords in a static password file or usernames and tokens in 30 00:02:48,230 --> 00:02:52,410 a static token file, or you can authenticate using certificates. 31 00:02:52,910 --> 00:02:59,570 And another option is to connect to third party authentication protocols like that Kerberos, etc.. 32 00:03:00,260 --> 00:03:02,030 We will look at some of these next. 33 00:03:03,270 --> 00:03:08,430 Let's start with static password and token files as it is the easiest to understand. 34 00:03:09,520 --> 00:03:15,370 Let's start with the simplest form of authentication, you can create a list of users and their passwords 35 00:03:15,370 --> 00:03:20,000 in a case file and use that as the source for user information. 36 00:03:20,740 --> 00:03:28,810 The file has three columns password, username and user I.D. Within the file name has an option to the 37 00:03:28,810 --> 00:03:29,980 Cube API server. 38 00:03:31,240 --> 00:03:37,480 Remember the civil service and the various options we looked at earlier in this course, that is where 39 00:03:37,480 --> 00:03:43,390 you must specify this option, you must then restart the Cuban server for these options to take effect. 40 00:03:44,230 --> 00:03:50,110 If you set up your cluster using the Keverian to, then you must modify the Cuba space over pod definition 41 00:03:50,110 --> 00:03:50,470 file. 42 00:03:50,920 --> 00:03:56,380 The Cuban yamata will automatically restart the Kubica server once you update this file. 43 00:03:57,460 --> 00:04:03,670 To authenticate using the basic credentials while accessing the API server, specify the user and password 44 00:04:03,850 --> 00:04:05,770 in a command like this. 45 00:04:09,900 --> 00:04:15,720 In The Cafferty File with the user details that we saw, we can optionally have a fourth column with 46 00:04:15,720 --> 00:04:18,750 the group details to assign users to specific groups. 47 00:04:19,940 --> 00:04:26,270 Similarly, instead of a static password file, you can have a static token file here instead of password, 48 00:04:26,630 --> 00:04:34,880 you specify a token pass the token file as an option token or file to the server while authenticating 49 00:04:34,880 --> 00:04:37,670 specified a token as an authorization bearer. 50 00:04:37,690 --> 00:04:39,650 Token to your request like this. 51 00:04:42,280 --> 00:04:43,370 That's it for this lecture. 52 00:04:43,570 --> 00:04:49,780 Remember that this authentication mechanism that stores usernames, passwords and tokens and clear text 53 00:04:49,780 --> 00:04:54,390 in a static file is not a recommended approach as it is insecure. 54 00:04:54,820 --> 00:04:59,830 But I thought this was the easiest way to understand the basics of authentication and communities going 55 00:04:59,830 --> 00:05:00,310 forward. 56 00:05:00,680 --> 00:05:02,950 We will look at other authentication mechanisms. 57 00:05:03,880 --> 00:05:09,970 I also want to point out that if you were trying this out in a cupboard's setup, you must also consider 58 00:05:10,180 --> 00:05:11,940 volume mounts to passing the out. 59 00:05:11,950 --> 00:05:15,750 Final details about these are available in the article that follows. 60 00:05:15,760 --> 00:05:19,030 And remember to set up authorization for the new users. 61 00:05:19,970 --> 00:05:25,700 We will discuss about authorization later in this course in the upcoming lectures, we will discuss 62 00:05:25,700 --> 00:05:31,700 about certificate based authentication and how the various components within this cluster are secured 63 00:05:31,910 --> 00:05:33,290 using certificates.