WEBVTT

00:00.547 --> 00:02.604
Hello, and welcome to this lecture.

00:02.604 --> 00:03.568
In this lecture,

00:03.568 --> 00:06.552
we look at securing
your Kubernetes cluster

00:06.552 --> 00:08.453
with TLS certificates.

00:08.766 --> 00:12.802
In the previous lecture,
we saw what public and private keys are,

00:13.245 --> 00:17.531
how a server uses public and private keys
to secure connectivity.

00:17.531 --> 00:20.292
We will call them serving certificates.

00:20.734 --> 00:23.334
We saw what a certificate authority is.

00:23.469 --> 00:27.245
We learned that the CA has its own set
of public and private key pairs

00:27.245 --> 00:30.266
that it uses to sign 
 server certificates.

00:30.552 --> 00:32.766
We will call them root certificates.

00:32.870 --> 00:36.792
We also saw how a server
can request a client

00:36.792 --> 00:39.776
to verify themselves 
using client certificates.

00:40.063 --> 00:42.015
Three types of certificates,

00:42.198 --> 00:44.802
server certificates configured 
on those servers,

00:44.802 --> 00:48.240
root certificate configured
 on the CA servers,

00:48.396 --> 00:51.313
and then client certificates configured
 on the clients.

00:51.313 --> 00:54.880
A quick note on naming convention, 
before we go forward,

00:55.115 --> 00:58.620
you're going to see a lot
of certificate files in this lecture,

00:58.620 --> 01:00.469
and it could be very confusing.

01:00.964 --> 01:04.260
Use this technique to know 
which one is which.

01:04.443 --> 01:10.094
Usually, certificates with public keys 
are named CRT or PEM extension,

01:10.094 --> 01:14.286
so that's server.crt or server.pem
for server certificates

01:14.286 --> 01:18.401
or client.crt or client.pem 
for client certificates.

01:18.740 --> 01:21.750
Private keys
are usually with extension .key

01:21.750 --> 01:24.354
or with a -key in the file names,

01:24.354 --> 01:28.000
for example,
server.key or server-key.pem.

01:28.651 --> 01:32.938
Just remember private keys 
have the word key in them usually

01:33.198 --> 01:36.167
either as an extension 
or in the name of the certificate.

01:36.635 --> 01:39.396
One that doesn't have 
the word key in them

01:39.396 --> 01:42.052
is usually a public key
or certificate.

01:42.313 --> 01:43.797
That's how I remember it.

01:44.474 --> 01:48.448
We will now see how these concepts
relate to a Kubernetes cluster.

01:49.646 --> 01:54.359
The Kubernetes cluster consists of 
a set of master and worker nodes.

01:54.698 --> 01:57.969
Of course, all communication
between these nodes

01:57.969 --> 02:01.146
need to be secure 
and must be encrypted.

02:01.432 --> 02:05.052
All interactions between
all services and their clients

02:05.220 --> 02:06.835
need to be secure.

02:07.344 --> 02:10.901
For example, an administrator
interacting with the Kubernetes cluster

02:10.901 --> 02:12.750
through the Kube-control utility,

02:12.750 --> 02:16.031
or while accessing
the Kubernetes API directly

02:16.031 --> 02:19.182
must establish secure TLS connection.

02:19.443 --> 02:23.182
Communication between all the components
within the Kubernetes cluster

02:23.426 --> 02:25.266
also need to be secured.

02:25.656 --> 02:28.432
The two primary requirements
are to have

02:28.432 --> 02:30.870
all the various services
within the cluster

02:30.870 --> 02:32.365
to use server certificates

02:32.365 --> 02:37.755
and all clients to use client certificates
to verify they are who they say they are.

02:38.302 --> 02:41.469
Let's look at the different components 
within the Kubernetes cluster

02:41.469 --> 02:45.635
and identify the various servers 
and clients and who talks to who.

02:46.104 --> 02:48.240
Let's start with the Kube-api Server.

02:48.474 --> 02:49.880
As we know already,

02:49.880 --> 02:53.750
the API server exposes 
an HTTPS service

02:53.750 --> 02:56.484
that other components
as well as external users

02:56.484 --> 02:58.750
use to manage the Kubernetes cluster,

02:59.193 --> 03:00.495
so it is a server

03:00.495 --> 03:05.142
and it requires certificates to secure
all communication with its clients.

03:05.521 --> 03:07.646
We generate a certificate
and key pair,

03:07.646 --> 03:12.255
we call it apiserver.cert 
and apiserver.key.

03:12.646 --> 03:16.099
We will try to stick to 
this naming convention going forward.

03:16.438 --> 03:19.745
Anything with a .CRT extension
 is the certificate

03:19.745 --> 03:22.714
and .key extension
is the private key.

03:23.260 --> 03:25.464
Also remember,
the certificate names

03:25.464 --> 03:28.083
could be different
in different Kubernetes setups

03:28.083 --> 03:30.766
depending on who 
and how the cluster was set up,

03:30.922 --> 03:33.370
so these names 
may be different in yours.

03:33.656 --> 03:35.844
In this lecture, 
we will try to use names

03:35.844 --> 03:39.151
that help us easily identify 
the certificate files.

03:39.880 --> 03:43.526
Another server in the cluster 
is the ETCD server.

03:43.786 --> 03:46.797
The ETCD server stores 
all information about the cluster,

03:46.797 --> 03:50.146
so it requires a pair 
of certificate and key for itself.

03:50.313 --> 03:55.495
We will call it etcdserver.crt 
and etcdserver.key.

03:56.172 --> 03:59.948
The other server component in the cluster 
is on the worker nodes.

03:59.948 --> 04:01.510
They are the Kubelet services.

04:01.510 --> 04:06.708
They also expose an HTTPS API endpoint
that the Kube-api server talks to

04:06.943 --> 04:08.609
to interact with worker nodes.

04:08.609 --> 04:11.552
Again, that requires
a certificate and key pair.

04:11.552 --> 04:15.328
We call it kubelet.cert 
and kubelet.key.

04:16.135 --> 04:19.536
Those are really the server components 
in the Kubernetes cluster.

04:20.370 --> 04:22.651
Let's now look at
the client components.

04:22.885 --> 04:25.307
Who are the clients
who access these services?

04:25.932 --> 04:28.526
The clients who access
 the Kube-api servers

04:28.526 --> 04:30.651
are us, the administrators,

04:30.818 --> 04:32.849
through Kube control or REST API.

04:33.422 --> 04:36.120
The admin user requires 
a certificate and key pair

04:36.120 --> 04:38.359
to authenticate
to the Kube-api Server.

04:38.594 --> 04:42.188
We will call it admin.crt 
and admin.key.

04:42.577 --> 04:44.911
The scheduler talks 
to the Kube-api Server

04:44.911 --> 04:47.202
to look for pods
that require scheduling

04:47.202 --> 04:50.405
and then get the API server
to schedule the pods

04:50.405 --> 04:51.916
on the right worker notes.

04:52.306 --> 04:56.146
The scheduler is a client 
that accesses the Kube-api Server.

04:56.228 --> 04:58.666
As far as the Kube-api Server 
is concerned,

04:58.848 --> 05:02.702
the scheduler is just another client
like the admin user.

05:02.702 --> 05:05.583
The scheduler needs to
 validate its identity

05:05.583 --> 05:07.770
using a client TLS certificate.

05:07.770 --> 05:10.973
It needs its own pair 
of certificate and keys,

05:11.208 --> 05:14.984
we will call it scheduler.crt 
and scheduler.key.

05:15.921 --> 05:18.411
The kube-controller-manager 
is another client

05:18.411 --> 05:20.520
that accesses the kube-api server,

05:20.520 --> 05:24.739
so it also requires a certificate 
for authentication to the kube-api server

05:24.739 --> 05:27.135
so we create
a certificate pair for it.

05:27.838 --> 05:31.119
The last client component 
is the kube-proxy.

05:31.119 --> 05:33.609
The kube-proxy requires 
a client certificate

05:33.609 --> 05:35.614
to authenticate
to the kube-api server,

05:35.614 --> 05:39.353
and so it requires its own pair
of certificate and keys.

05:39.562 --> 05:44.197
We will call them kube-proxy.crt 
and kube-proxy.key.

05:44.327 --> 05:46.713
The servers communicate 
amongst them as well.

05:46.713 --> 05:50.947
For example, the kube-api server 
communicates with the etcd server.

05:51.103 --> 05:53.083
In fact, of all the components,

05:53.083 --> 05:57.770
the kube-api server is the only server
that talks to the etcd server.

05:57.770 --> 06:00.218
As far as the etcd server 
is concerned,

06:00.218 --> 06:04.010
the kube-api server is a client,
so it needs to authenticate

06:04.010 --> 06:06.900
the kube-api server 
can use the same keys

06:06.900 --> 06:10.598
that it used earlier 
for serving its own API service,

06:10.989 --> 06:14.687
the apiserver.crt 
and the apiserver.key files.

06:14.843 --> 06:17.984
Or you can generate 
a new pair of certificates

06:17.984 --> 06:22.567
specifically for the kube-api server
to authenticate to the etcd server.

06:23.218 --> 06:26.864
The kube-api server
also talks to the kubelet server

06:26.864 --> 06:28.765
on each of the individual nodes.

06:28.765 --> 06:31.072
That's how it monitors
the worker nodes.

06:31.176 --> 06:34.405
For this, again, it can use 
the original certificates

06:34.405 --> 06:37.530
or generate new ones
specifically for this purpose.

06:38.338 --> 06:41.583
That's too many certificates, 
let's try and group them.

06:42.025 --> 06:44.176
There are a set of client certificates

06:44.176 --> 06:47.353
mostly used by clients
to connect to the kube-api server,

06:47.561 --> 06:49.958
and there are a set 
of server side certificates

06:49.958 --> 06:53.864
used by the kube-api server, 
etcd server, and kubelet

06:53.864 --> 06:56.051
to authenticate their clients.

06:56.598 --> 06:59.296
We will now see
how to generate these certificates.

06:59.504 --> 07:00.598
As we know already,

07:00.598 --> 07:04.609
we need a certificate authority 
to sign all of these certificates.

07:04.609 --> 07:06.562
Kubernetes requires you to have

07:06.822 --> 07:10.234
at least one certificate authority
for your cluster.

07:10.442 --> 07:12.515
In fact, you can have more than one,

07:12.853 --> 07:15.119
one for all the components 
in the cluster,

07:15.119 --> 07:17.713
and another one 
specifically for etcd.

07:17.713 --> 07:18.572
In that case,

07:18.572 --> 07:22.973
the etcd servers certificates
and the etcd servers client certificates,

07:23.155 --> 07:26.202
which in this case 
is the apiserver client certificate

07:26.202 --> 07:29.848
will be all signed 
by the etcd server CA.

07:30.369 --> 07:34.003
For now, we will stick to just one CA 
for our cluster.

07:34.263 --> 07:35.904
The CA as we know

07:35.904 --> 07:39.159
has its own pair
of certificate and key,

07:39.523 --> 07:43.378
we will call it ca.crt and ca.key.

07:44.315 --> 07:47.570
That should sum up all the certificates
used in the cluster.