1

00:00:00,570 --> 00:00:06,510

So far, we talked about authentication, we saw how someone can gain access to a cluster.



2

00:00:06,570 --> 00:00:12,750

We saw different ways that someone, a human or a machine, can get access to the cluster once they



3

00:00:12,750 --> 00:00:13,660

gain access.



4

00:00:13,890 --> 00:00:14,970

What can they do?



5

00:00:15,430 --> 00:00:17,550

That's what authorization defines.



6

00:00:19,040 --> 00:00:22,100

First of all, why do you need authorization in your cluster?



7

00:00:23,110 --> 00:00:28,900

As an administrator of the cluster, we were able to perform all sorts of operations in it, such as



8

00:00:28,900 --> 00:00:35,860

viewing various objects like ports and nodes and deployments, creating or deleting objects such as



9

00:00:35,860 --> 00:00:39,010

adding or deleting parts or even nodes in the cluster.



10

00:00:39,730 --> 00:00:42,880

As an admin, we are able to perform any operation.



11

00:00:43,840 --> 00:00:50,050

But soon we will have others accessing the cluster as well, such as the other administrators, developers,



12

00:00:50,050 --> 00:00:56,290

testers or other applications like monitoring applications or continuous delivery applications like



13

00:00:56,290 --> 00:00:57,330

jenkins', etc..



14

00:00:58,370 --> 00:01:04,190

So we will be creating accounts for them to access the cluster by creating usernames and passwords or



15

00:01:04,190 --> 00:01:09,470

tokens or assigned certificates or service accounts, as we saw in the previous lecture's.



16

00:01:10,440 --> 00:01:16,170

But we don't want all of them to have the same level of access as us, for example, we don't want the



17

00:01:16,170 --> 00:01:22,610

developers to have access to modify our cluster configuration, like adding or deleting nodes or the



18

00:01:22,620 --> 00:01:24,660

storage or networking configurations.



19

00:01:25,660 --> 00:01:31,810

We can allow them to view, but not modify, but they could have access to deploy applications, the



20

00:01:31,810 --> 00:01:33,270

same goes with service accounts.



21

00:01:33,610 --> 00:01:39,970

We only want to provide the external application, the minimum level of access to perform its required



22

00:01:39,970 --> 00:01:40,660

operations.



23

00:01:41,350 --> 00:01:47,800

When we share our cluster between different organizations or teams by logically partitioning it using



24

00:01:47,800 --> 00:01:53,600

name spaces, we want to restrict access to the users, to their name spaces alone.



25

00:01:54,340 --> 00:01:58,000

That is what authorization can help you within the cluster.



26

00:01:58,920 --> 00:02:04,230

There are different authorization mechanisms supported by communities such as Noad, authorization,



27

00:02:04,410 --> 00:02:08,430

attribute based authorization, rule-based authorization and Web Hook.



28

00:02:09,180 --> 00:02:10,410

Let us go through this now.



29

00:02:12,270 --> 00:02:18,900

We know that the Cuba server is accessed by users like us for management purposes as well as the Cubans



30

00:02:18,900 --> 00:02:25,140

on note, within the cluster for medicinal purposes, within the cluster, the Cuba that accesses the



31

00:02:25,600 --> 00:02:31,770

server to read information about services and points north and parts to Cuba, and also reports to the



32

00:02:31,770 --> 00:02:35,470

Cuba server with information about the note such as its status.



33

00:02:36,300 --> 00:02:42,120

These requests are handled by a special authorizer known as the node authorizer.



34

00:02:43,150 --> 00:02:48,580

In the early lecture's when we discussed about Certificate's, we discussed that the tubeless should



35

00:02:48,580 --> 00:02:53,520

be part of this system node's group and have a name prefixed with system known.



36

00:02:54,280 --> 00:03:01,390

So any requests coming from a user with the name system node and part of the system nodes group is authorized



37

00:03:01,390 --> 00:03:09,410

by the node authorizer and are granted these privileges the privileges required for a CubeSat so that



38

00:03:09,460 --> 00:03:10,870

access within the cluster.



39

00:03:12,910 --> 00:03:19,810

Let's talk about external access to the API, for instance, a user attribute based authorization is



40

00:03:19,810 --> 00:03:24,610

where you associate a user or a group of users with a set of permissions.



41

00:03:24,610 --> 00:03:29,440

In this case, we say the user can view, create and delete part.



42

00:03:30,070 --> 00:03:35,650

You do this by creating a policy file with a set of policies defined in adjacent format.



43

00:03:35,680 --> 00:03:39,280

This way you pass this file into the API server.



44

00:03:40,430 --> 00:03:46,040

Similarly, we create a policy definition file for each user or group in this file.



45

00:03:47,320 --> 00:03:55,480

Now, every time you need to add or make a change in the security, you must edit this policy file manually



46

00:03:55,480 --> 00:03:57,510

and restart the server.



47

00:03:57,970 --> 00:04:04,270

As such, the attribute based access control configurations are difficult to manage.



48

00:04:05,170 --> 00:04:07,840

We will look at role based access control to next.



49

00:04:09,040 --> 00:04:15,040

Role based access controls make this much easier with role based access controls, instead of directly



50

00:04:15,040 --> 00:04:22,080

associating a user or a group with a set of permissions, we define a role in this case for developers.



51

00:04:22,450 --> 00:04:26,460

We create a role with the set of permissions required for developers.



52

00:04:26,920 --> 00:04:29,870

Then we associate all the developers to that role.



53

00:04:30,520 --> 00:04:36,700

Similarly, create a role for security users with the right set of permissions required for them, then



54

00:04:36,700 --> 00:04:43,610

associate the user to that role going forward whenever a change needs to be made to the users access.



55

00:04:43,960 --> 00:04:48,610

We simply modify the role and it reflects on all developers immediately.



56

00:04:49,640 --> 00:04:55,190

Role based access control to provide a more standard approach to managing access within the communities



57

00:04:55,190 --> 00:04:55,700

cluster.



58

00:04:56,680 --> 00:05:01,270

We will look at role based access controls in much more detail in the next lecture.



59

00:05:02,200 --> 00:05:05,110

For now, let's proceed with the other authorization mechanisms.



60

00:05:06,500 --> 00:05:12,920

Now, what if you want to outsource all the authorisation mechanisms, say you want to manage authorization



61

00:05:12,920 --> 00:05:16,730

externally and not through the built in mechanisms that we just discussed?



62

00:05:17,640 --> 00:05:23,580

For instance, Open Policy Agent is a third party tool that helps with admission control and authorization.



63

00:05:24,520 --> 00:05:30,310

You can have communities make an API call to the open policy agent with the information about the user



64

00:05:30,310 --> 00:05:36,610

and his access requirements and have the open policy agent decide if the user should be permitted or



65

00:05:36,610 --> 00:05:36,930

not.



66

00:05:38,050 --> 00:05:40,690

Based on that response, the user is granted access.



67

00:05:42,260 --> 00:05:49,640

Now, there are two more modes, in addition to what we just saw, always allow and always deny, as



68

00:05:49,640 --> 00:05:57,080

the name states always allow allows all requests without performing any authorization checks, always



69

00:05:57,080 --> 00:05:59,450

deny denies all requests.



70

00:06:00,740 --> 00:06:04,470

So where do you configure these modes, which of them are active by default?



71

00:06:04,610 --> 00:06:06,450

Can you have more than one at a time?



72

00:06:07,070 --> 00:06:10,220

How does authorization work if you do have multiple ones configure?



73

00:06:11,550 --> 00:06:16,060

The molds are set using the authorization mode auction on the Cuba server.



74

00:06:16,740 --> 00:06:23,280

If you don't specify this option, it is said to always allow by default, you mean provide a comma



75

00:06:23,280 --> 00:06:26,430

separated list of multiple modes that you wish to use.



76

00:06:26,580 --> 00:06:31,740

In this case, I want to set it to node auerback and web hook.



77

00:06:32,810 --> 00:06:39,560

When you have multiple modes configured, your request is authorized using each one in the order it



78

00:06:39,560 --> 00:06:40,320

is specified.



79

00:06:40,640 --> 00:06:46,130

For example, when a user sends a request, it's first handled by the node authorizer.



80

00:06:46,640 --> 00:06:49,700

The node authorizer handles only no request.



81

00:06:51,290 --> 00:06:58,010

So it denies the request, whenever a module denies a request, it is forwarded to the next one in the



82

00:06:58,010 --> 00:06:58,360

chain.



83

00:06:59,090 --> 00:07:04,370

The role based access control module performs its checks and grabs the user permission.



84

00:07:05,030 --> 00:07:09,470

Authorization is complete and user is given access to the requested object.



85

00:07:10,220 --> 00:07:15,380

So every time a module denies the request, it goes to the next one in the chain.



86

00:07:15,650 --> 00:07:21,710

And as soon as a module approves the request, no more checks are done and the user is granted permission.



87

00:07:22,620 --> 00:07:28,710

Well, that's it for this lecture in the upcoming lectures, we will discuss more about rule-based access



88

00:07:28,710 --> 00:07:29,220

controls.