WEBVTT

00:00.130 --> 00:02.188
Hello and welcome to this lecture.

00:02.188 --> 00:06.693
In this lecture,  we will talk about
security context in Kubernetes.

00:06.875 --> 00:08.464
Before we get into that,

00:08.672 --> 00:12.786
it is important to have some knowledge
about security in Docker.

00:13.099 --> 00:15.729
If you're familiar
with security in Docker,

00:15.729 --> 00:18.750
feel free to skip this lecture 
and head over to the next.

00:19.245 --> 00:22.047
In this lecture, we will look at 
the various concepts

00:22.047 --> 00:24.573
related to security in Docker.

00:25.250 --> 00:28.844
Let us start with a host
with Docker installed on it.

00:29.495 --> 00:33.234
This host has a set
of its own processes running

00:33.234 --> 00:36.542
such as a number of 
operating system processes,

00:36.542 --> 00:39.901
the Docker daemon itself, 
the SSH server, et cetera.

00:40.552 --> 00:43.573
We will now run 
an Ubuntu Docker container

00:43.573 --> 00:46.333
that runs a process
that sleeps for an hour.

00:47.193 --> 00:49.839
We have learned that,
unlike virtual machines,

00:49.839 --> 00:53.536
containers are not completely isolated
from their host.

00:53.875 --> 00:57.011
Containers and their hosts 
hare the same kernel.

00:57.313 --> 01:01.193
Containers are isolated 
using namespaces in Linux.

01:01.714 --> 01:03.354
The host has a namespace

01:03.354 --> 01:06.089
and the containers 
have their own namespace.

01:06.807 --> 01:09.385
All the processes
run by the containers

01:09.385 --> 01:12.276
are in fact run on the host itself

01:12.484 --> 01:14.672
but in their own namespace.

01:15.401 --> 01:17.995
As far as the Docker container 
 is concerned,

01:17.995 --> 01:20.026
it is in its own namespace,

01:20.026 --> 01:22.917
and it can see
its own processes only.

01:23.073 --> 01:27.839
It cannot see anything outside of it, 
or in any other namespace.

01:28.296 --> 01:31.995
When you list the processes 
from within the Docker container,

01:31.995 --> 01:35.641
you see the sleep process 
with a process ID of one.

01:36.370 --> 01:37.802
For the Docker host,

01:37.802 --> 01:42.099
all processes of its own, 
as well as those in the child namespaces

01:42.099 --> 01:45.526
are visible as just another process
in the system.

01:45.865 --> 01:48.599
When you list the processes
on the host,

01:48.599 --> 01:52.427
you see a list of processes,
including the sleep command,

01:52.427 --> 01:54.589
but with a different process ID.

01:55.004 --> 01:57.442
This is because the processes
can have

01:57.442 --> 02:00.619
different process IDs 
in different namespaces

02:00.619 --> 02:04.265
and that's how Docker
isolates containers within a system.

02:05.072 --> 02:07.363
That's process isolation.

02:08.874 --> 02:12.562
Let us now look at users
in context of security.

02:13.004 --> 02:15.687
The Docker host has a set of users,

02:15.687 --> 02:19.374
a root user as well as 
a number of non-root users.

02:19.817 --> 02:24.921
By default, Docker runs processes 
within containers as the root user.

02:25.390 --> 02:29.010
This can be seen in the output 
of the commands we ran earlier,

02:29.478 --> 02:33.280
both within the container
and outside the container on the host,

02:33.515 --> 02:36.275
the process is run as the root user.

02:36.942 --> 02:40.369
Now, if you do not want
the process within the container

02:40.369 --> 02:42.296
to run as the root user,

02:42.296 --> 02:46.879
you may set the user using the user option
within the Docker run command

02:46.879 --> 02:49.275
and specify the new user ID.

02:49.640 --> 02:54.015
You will see that the process now runs
with the new user ID.

02:54.379 --> 02:57.103
Another way to enforce user security

02:57.103 --> 03:00.359
is to have this defined 
in the Docker image itself

03:00.359 --> 03:01.921
at the time of creation.

03:02.207 --> 03:05.697
For example, we will use
the default Ubuntu image

03:05.697 --> 03:10.102
and set the user ID to 1000 
using the user instruction,

03:10.504 --> 03:12.770
then build a custom image.

03:13.093 --> 03:17.093
We can now run this image
without specifying the user ID

03:17.093 --> 03:21.051
and the process will be run 
with the user ID 1000.

03:21.858 --> 03:23.682
Let us take a step back.

03:23.890 --> 03:27.223
What happens when you run containers
as the root user?

03:27.432 --> 03:31.911
Is the root user within the container
the same as the root user on the host?

03:32.353 --> 03:34.374
Can the process inside the container

03:34.374 --> 03:37.682
do anything that the root user can do
on the system?

03:38.020 --> 03:40.103
If so, isn't that dangerous?

03:40.286 --> 03:43.697
Well, Docker implements 
a set of security features

03:43.905 --> 03:47.864
that limits the abilities of the root user
within the container.

03:48.150 --> 03:50.650
The root user within the container

03:50.650 --> 03:53.619
isn't really like the root user
on the host.

03:54.635 --> 03:58.530
Docker uses Linux capabilities
to implement this.

03:58.712 --> 04:03.374
As we all know, the root user 
is the most powerful user on a system,

04:03.530 --> 04:06.187
the root user can literally
do anything,

04:06.525 --> 04:09.624
and so does a process
run by the root user.

04:09.833 --> 04:12.895
It has unrestricted access
to the system,

04:12.895 --> 04:16.072
from modifying files
and permissions on files,

04:16.072 --> 04:17.400
access control,

04:17.400 --> 04:19.343
creating or killing processes,

04:19.343 --> 04:21.791
setting group ID or user ID,

04:21.958 --> 04:26.501
performing network-related operations
such as binding to network ports,

04:26.668 --> 04:28.546
broadcasting on a network,

04:28.546 --> 04:30.447
controlling network ports,

04:30.447 --> 04:33.598
system-related operations 
like rebooting the host,

04:33.728 --> 04:36.437
manipulating system clock,
and many more.

04:37.208 --> 04:41.208
All of these are the different capabilities
on a Linux system

04:41.208 --> 04:44.228
and you can see a full list 
at this location.

04:45.296 --> 04:47.275
You can now control and limit

04:47.275 --> 04:50.426
what capabilities are made available
to a user.

04:50.921 --> 04:56.015
By default, Docker runs a container 
with a limited set of capabilities.

04:56.145 --> 04:59.140
The processes running
 within the container

04:59.140 --> 05:01.770
do not have the privileges to say,

05:01.770 --> 05:04.895
reboot the host 
or perform operations that can

05:04.895 --> 05:08.645
disrupt the host or other containers
 running on the same host.

05:09.635 --> 05:11.708
If you wish to override this behavior

05:11.708 --> 05:15.119
and provide additional privileges 
than what is available,

05:15.223 --> 05:18.504
use the cap-add option 
in the Docker run command.

05:19.338 --> 05:24.364
Similarly, you can drop privileges 
as well using the cap-drop option,

05:24.917 --> 05:29.292
or in case you wish to run the container
with all privileges enabled,

05:29.292 --> 05:31.036
use the privileged flag.

05:31.844 --> 05:34.760
Well, that's it
on Docker security for now.

05:34.760 --> 05:36.870
I will see you in the next lecture.