WEBVTT

00:00.945 --> 00:04.710
-In this lecture,
we will talk about securing images.

00:05.760 --> 00:08.563
We will start with the basics
of image names

00:08.730 --> 00:11.970
and then work our way towards
secure image repositories

00:12.300 --> 00:17.010
and how to configure your pods to
use images from secure repositories.

00:17.910 --> 00:20.623
We deployed a number of different
kinds of pods hosting

00:20.790 --> 00:23.923
different kinds of applications
throughout this course, like web apps

00:24.090 --> 00:26.715
and databases and Redis, cache, et cetera.

00:27.390 --> 00:30.870
Let’s start with a simple pod
definition file for instance.

00:31.140 --> 00:35.670
Here, we have used the nginx image
to deploy an nginx container.

00:36.690 --> 00:39.378
Let’s take a closer
look at this image name.

00:39.930 --> 00:45.540
The name is nginx, but what is this image
and where is this image pull from?

00:46.590 --> 00:49.650
This name follows Docker’s
image naming convention.

00:50.370 --> 00:53.910
Nginx here is the image
or the repository name.

00:56.460 --> 01:01.320
-When you say nginx,
it’s actually library/nginx.

01:01.740 --> 01:05.430
The first part stands
for the user or the account name.

01:05.760 --> 01:11.040
If you don’t provide a user or account
name, it assumes it to be library.

01:11.280 --> 01:14.023
Library is the name of the default account

01:14.190 --> 01:17.070
where Docker’s official images are stored.

01:17.460 --> 01:19.363
These images promote best practices

01:19.530 --> 01:23.323
and are maintained by a dedicated
team who are responsible for reviewing

01:23.490 --> 01:25.803
and publishing these official images.

01:26.040 --> 01:30.660
Now, if you were to create your own
account and create your own repositories

01:31.080 --> 01:34.710
or images under it,
then you would use a similar pattern.

01:34.920 --> 01:39.420
Instead of library, it would be
your name or your company’s name.

01:41.070 --> 01:44.670
Now, where are these images
stored and pulled from?

01:47.220 --> 01:50.083
Since we have not specified the location

01:50.250 --> 01:52.860
where these images are to be pulled from,

01:53.070 --> 01:57.060
it is assumed to be Docker’s
default registry, Docker Hub.

01:57.660 --> 01:59.910
The DNS name for which is docker.io.

02:00.720 --> 02:03.073
The registry is where all
the images are stored.

02:03.240 --> 02:06.163
Whenever you create a new
image or update an image,

02:06.330 --> 02:09.943
you push it to the registry, and every
time anyone deploys this application,

02:10.110 --> 02:11.743
it is pulled from the registry.

02:11.910 --> 02:14.810
There are many other
popular registries as well.

02:15.060 --> 02:18.210
Google’s registry is at gcr.io,

02:18.510 --> 02:21.553
where a lot of Kubernetes-related
images are stored,

02:21.720 --> 02:25.890
like the ones used for performing
end-to-end tests on the cluster.

02:27.390 --> 02:32.130
These are all publicly accessible images
that anyone can download and access.

02:32.490 --> 02:34.423
When you have applications built in-house

02:34.590 --> 02:37.003
that shouldn’t be made
available to the public,

02:37.170 --> 02:40.333
hosting an internal private
registry may be a good solution.

02:40.500 --> 02:44.280
Many cloud service providers such as AWS,
Azure, or GCP,

02:44.490 --> 02:46.865
provide a private registry by default.

02:47.340 --> 02:51.253
-On any of these solutions,
be it on Docker Hub or Google’s registry,

02:51.420 --> 02:56.280
or your internal private registry, you may
choose to make a repository private

02:56.460 --> 02:59.640
so that it can be accessed
using a set of credentials.

03:00.270 --> 03:04.740
From Docker’s perspective,
to run a container using a private image,

03:05.160 --> 03:09.480
you first log in to your private
registry using the Docker login command.

03:09.990 --> 03:11.670
Input your credentials.

03:12.300 --> 03:16.980
Once successful, run the application
using the image from the private registry.

03:19.170 --> 03:24.420
Going back to our pod definition file,
to use an image from our private registry,

03:24.660 --> 03:30.190
we replace the image name with the full
path to the one in the private registry.

03:30.510 --> 03:34.320
How do we implement the authentication,
the login part?

03:34.920 --> 03:39.120
How does Kubernetes get the credentials
to access the private registry?

03:39.570 --> 03:42.193
Within Kubernetes,
we know that the images are pulled

03:42.360 --> 03:45.450
and run by the Docker
runtime on the worker nodes.

03:45.960 --> 03:50.430
How do you pass the credentials to
the Docker runtime on the worker nodes?

03:51.330 --> 03:55.560
For that, we first create a secret
object with the credentials in it.

03:56.100 --> 04:01.170
The secret is of type Docker registry,
and we name it regcred.

04:02.040 --> 04:05.010
Docker registry is a built-in secret type

04:05.310 --> 04:08.670
that was built for storing
Docker credentials.

04:09.360 --> 04:14.040
We then specify the registry server name,
the user name to access the registry,

04:14.280 --> 04:17.180
the password,
and the email address of the user.

04:18.600 --> 04:21.553
We then specify the secret inside our pod

04:21.720 --> 04:25.380
definition file under
the image pull secret section.

04:26.160 --> 04:31.123
When the pod is created, Kubernetes
or the kubelets on the worker node uses

04:31.290 --> 04:34.350
the credentials from
the secret to pull images.

04:35.310 --> 04:37.183
Well, that’s it for this lecture.

04:37.350 --> 04:39.553
Head over to the practice
exercises section

04:39.720 --> 04:42.570
and practice working with secure images.