WEBVTT

00:00.600 --> 00:02.830
-So far we talked
about authentication.

00:03.550 --> 00:06.360
We saw how someone
can gain access to a cluster.

00:06.560 --> 00:09.950
We saw different ways that someone,
a human or a machine,

00:10.180 --> 00:11.700
can get access to the cluster.

00:12.090 --> 00:14.960
Once they gain access,
what can they do?

00:15.400 --> 00:17.480
That's what authorization defines.

00:18.950 --> 00:21.950
First of all, why do you need
authorization in your cluster?

00:23.080 --> 00:25.980
As an administrator of the cluster,
we were able to perform

00:26.150 --> 00:27.920
all sorts of operations in it

00:28.400 --> 00:32.560
such as viewing various objects
like pods and nodes and deployments.

00:33.330 --> 00:36.000
Creating or deleting objects
such as adding

00:36.160 --> 00:39.010
or deleting pods
or even nodes in the cluster.

00:39.760 --> 00:42.760
As an admin,
we are able to perform any operation.

00:43.760 --> 00:46.260
Soon, we will have
others accessing the cluster

00:46.420 --> 00:49.150
as well such
as the other administrators,

00:49.370 --> 00:52.060
developers, testers,
or other applications

00:52.490 --> 00:55.710
like monitoring applications
or continuous delivery applications

00:55.880 --> 00:57.260
like Jenkins et cetera.

00:58.350 --> 01:02.050
We will be creating accounts
for them to access the cluster

01:02.340 --> 01:04.520
by creating usernames
and passwords or tokens

01:04.690 --> 01:07.700
or signed [?] certificates
for service accounts

01:07.870 --> 01:09.620
as we saw in the previous lectures.

01:10.400 --> 01:14.340
We don't want all of them to have
the same level of access as us.

01:14.560 --> 01:17.330
For example, we don't want
the developers to have access

01:17.500 --> 01:21.070
to modify our cluster configuration
like adding or deleting nodes

01:21.930 --> 01:24.570
or the storage
or networking configurations.

01:25.740 --> 01:28.200
We can allow them to view,
but not modify.

01:28.900 --> 01:31.300
They could have access
to deploying applications.

01:31.540 --> 01:33.340
The same goes with service accounts.

01:33.630 --> 01:36.330
We only want to provide
the external application

01:36.570 --> 01:40.500
the minimum level of access
to perform its required operations.

01:41.400 --> 01:44.260
When we share our cluster
between different organizations

01:44.650 --> 01:48.600
or teams by logically partitioning it
using namespaces,

01:49.360 --> 01:51.870
we want to restrict access
to the users

01:52.050 --> 01:53.660
to their namespaces alone.

01:54.380 --> 01:57.980
That is what authorization
can help you within the cluster.

01:58.880 --> 02:00.800
There are different
authorization mechanisms

02:00.970 --> 02:02.120
supported by Kubernetes

02:02.580 --> 02:06.010
such as node authorization,
attribute-based authorization,

02:06.350 --> 02:08.260
role-based authorization,
and webhook.

02:09.030 --> 02:10.430
Let us go through these now.

02:12.130 --> 02:15.880
We know that the QB-API server
is accessed by users like us

02:16.050 --> 02:18.610
for management purposes
as well as the Kubelets

02:18.780 --> 02:21.330
on nodes within the cluster
for management purposes

02:21.500 --> 02:22.710
within the cluster.

02:23.590 --> 02:26.630
The Kubelet accesses
the API server to read information

02:26.790 --> 02:29.430
about services and points,
nodes, and pods.

02:29.930 --> 02:32.350
The Kubelet also reports
to the QB-API server

02:32.520 --> 02:35.380
with information
about the node such as its status.

02:36.260 --> 02:39.690
These requests are handled
by a special authorizer

02:39.860 --> 02:42.330
known as the node authorizer.

02:43.210 --> 02:45.820
In the earlier lectures when
we discussed about such figures,

02:45.990 --> 02:48.570
we discussed that the Kubelets
should be part

02:48.730 --> 02:51.990
of this system nodes group
and have a name prefixed

02:52.160 --> 02:53.530
with system node.

02:54.210 --> 02:58.230
Any requests coming from a user
with the name system node

02:58.400 --> 03:02.880
and part of the system nodes group
is authorized by the node authorizers

03:03.250 --> 03:05.050
and are granted these privileges.

03:05.740 --> 03:07.870
The privileges required
for a Kubelet.

03:08.840 --> 03:10.800
That's access within the cluster.

03:12.970 --> 03:15.400
Let's talk about external access
to the API.

03:15.800 --> 03:17.070
For instance, a user.

03:17.720 --> 03:20.410
Attribute-based authorization
is where you associate

03:20.580 --> 03:24.440
a user or a group of users
with a set of permissions.

03:24.650 --> 03:29.360
In this case, we say the dev user
can view, create, and delete pods.

03:30.050 --> 03:32.510
You do this by creating a policy file

03:32.740 --> 03:36.320
with a set of policies defined
in a JSON format this way.

03:36.770 --> 03:39.140
You pass this file
into the API server.

03:40.320 --> 03:42.660
Similarly,
we create a policy definition file

03:42.820 --> 03:46.070
for each user or group in this file.

03:47.280 --> 03:51.690
Now, every time you need to add
or make a change in the security,

03:52.240 --> 03:55.100
you must edit this policy file
manually

03:55.270 --> 03:57.350
and restart the QB-API server.

03:58.000 --> 04:02.050
As such, the attributes-based
access control configurations

04:02.220 --> 04:04.190
are difficult to manage.

04:05.160 --> 04:07.720
We will look at role-based
access controls next.

04:09.030 --> 04:11.850
Role-based access controls
make this much easier.

04:12.210 --> 04:15.470
With role-based access controls,
instead of directly associating

04:15.630 --> 04:18.120
a user or a group
with a set of permissions,

04:18.610 --> 04:19.930
we define a role.

04:20.210 --> 04:22.070
In this case, for developers.

04:22.400 --> 04:24.800
We create a role
with the set of permissions

04:24.970 --> 04:26.330
required for developers.

04:26.860 --> 04:29.770
Then we associate
all the developers to that role.

04:30.450 --> 04:33.200
Similarly, create a role
for security users

04:33.390 --> 04:35.940
with the right set of permissions
required for them.

04:36.260 --> 04:40.200
Then associate the user
to that role going forward.

04:40.460 --> 04:43.560
Whenever a change needs
to be made to the users access,

04:43.890 --> 04:46.220
we simply modify the role
and it reflects

04:46.380 --> 04:48.340
on all developers immediately.

04:49.580 --> 04:52.830
Role-based access control provide
a more standard approach

04:53.000 --> 04:55.620
to managing access
within the Kubernetes cluster.

04:56.690 --> 04:58.370
We will look
at role-based access controls

04:58.540 --> 05:01.260
in much more detail
in the next lecture.

05:02.210 --> 05:05.310
For now, let's proceed with
the other authorization mechanisms.

05:06.510 --> 05:10.230
Now, what if you want to outsource
all the authorization mechanisms.

05:10.760 --> 05:13.380
Say you want to manage
authorization externally

05:13.550 --> 05:15.340
and not through
the built-in mechanisms

05:15.510 --> 05:16.750
that we just discussed.

05:17.750 --> 05:21.230
For instance, Open Policy agent
is a third party tool that helps

05:21.400 --> 05:23.500
with admission control
and authorization.

05:24.450 --> 05:28.330
You can have Kubernetes make an API
call to the open policy agent

05:28.520 --> 05:31.830
with the information about the user
and his access requirements.

05:32.230 --> 05:36.110
Have the Open Policy agent decide
if the user should be permitted

05:36.280 --> 05:37.280
or not.

05:38.010 --> 05:40.510
Based on that response,
the user is granted access.

05:42.140 --> 05:45.770
Now, there are two more modes
in addition to what we just saw.

05:46.670 --> 05:48.560
Always allow and always deny.

05:49.420 --> 05:53.410
As the names states,
always allow allows all requests

05:53.570 --> 05:55.720
without performing
any authorization checks.

05:56.650 --> 05:59.390
Always deny denies all requests.

06:00.730 --> 06:02.480
Where do you configure these modes?

06:02.720 --> 06:04.480
Which of them are active by default?

06:04.650 --> 06:06.450
Can you have more
than one at a time?

06:07.000 --> 06:10.350
How does authorization work if you
do have multiple ones configured?

06:11.570 --> 06:14.560
The modes are set using
the authorization mode option

06:14.720 --> 06:16.000
on the QB-API server.

06:16.710 --> 06:21.380
If you don't specify this option,
it is set to always allow by default.

06:22.200 --> 06:24.970
You may provide a comma-separated
list of multiple modes

06:25.140 --> 06:26.290
that you wish to use.

06:26.560 --> 06:31.680
In this case, I want to set it
to node RBAC and webhook.

06:32.740 --> 06:35.010
When you have
multiple modes configured,

06:35.350 --> 06:39.160
your request is authorized using
each one in the order

06:39.320 --> 06:40.320
it is specified.

06:40.710 --> 06:43.020
For example,
when a user sends a request,

06:43.180 --> 06:46.120
it's first handled
by the node authorizer.

06:46.630 --> 06:49.610
The node authorizer handles
only node requests.

06:51.310 --> 06:52.710
It denies the request.

06:53.310 --> 06:57.460
Whenever a module denies a request,
it is forwarded to the next one

06:57.620 --> 06:58.620
in the chain.

06:59.080 --> 07:03.100
The role-based access control module
performs its checks and grants

07:03.270 --> 07:04.310
the user permission.

07:05.000 --> 07:07.930
Authorization is complete
and user is given access

07:08.140 --> 07:09.410
to the requested object.

07:11.140 --> 07:14.610
Every time a module denies a request,
it goes to the next one

07:14.780 --> 07:15.510
in the chain.

07:15.680 --> 07:18.510
As soon as a module
approves the request,

07:18.730 --> 07:21.690
no more checks are done
and the user is granted permission.

07:22.560 --> 07:24.260
Well, that's it for this lecture.

07:24.640 --> 07:26.760
In the upcoming lectures,
we will discuss

07:26.920 --> 07:29.320
more about role-based
access controls.