Hello, and welcome to this lecture.
In this lecture,
we look at securing your Kubernetes cluster
with TLS certificates.
In the previous lecture, we saw what public and private keys are,
how a server uses public and private keys to secure connectivity.
We will call them serving certificates.
We saw what a certificate authority is.
We learned that the CA has its own set of public and private key pairs
that it uses to sign server certificates.
We will call them root certificates.
We also saw how a server can request a client
to verify themselves using client certificates.
Three types of certificates,
server certificates configured on those servers,
root certificate configured on the CA servers,
and then client certificates configured on the clients.
A quick note on naming convention, before we go forward,
you're going to see a lot of certificate files in this lecture,
and it could be very confusing.
Use this technique to know which one is which.
Usually, certificates with public keys are named CRT or PEM extension,
so that's server.crt or server.pem for server certificates
or client.crt or client.pem for client certificates.
Private keys are usually with extension .key
or with a -key in the file names,
for example, server.key or server-key.pem.
Just remember private keys have the word key in them usually
either as an extension or in the name of the certificate.
One that doesn't have the word key in them
is usually a public key or certificate.
That's how I remember it.
We will now see how these concepts relate to a Kubernetes cluster.
The Kubernetes cluster consists of a set of master and worker nodes.
Of course, all communication between these nodes
need to be secure and must be encrypted.
All interactions between all services and their clients
need to be secure.
For example, an administrator interacting with the Kubernetes cluster
through the Kube-control utility,
or while accessing the Kubernetes API directly
must establish secure TLS connection.
Communication between all the components within the Kubernetes cluster
also need to be secured.
The two primary requirements are to have
all the various services within the cluster
to use server certificates
and all clients to use client certificates to verify they are who they say they are.
Let's look at the different components within the Kubernetes cluster
and identify the various servers and clients and who talks to who.
Let's start with the Kube-api Server.
As we know already,
the API server exposes an HTTPS service
that other components as well as external users
use to manage the Kubernetes cluster,
so it is a server
and it requires certificates to secure all communication with its clients.
We generate a certificate and key pair,
we call it apiserver.cert and apiserver.key.
We will try to stick to this naming convention going forward.
Anything with a .CRT extension is the certificate
and .key extension is the private key.
Also remember, the certificate names
could be different in different Kubernetes setups
depending on who and how the cluster was set up,
so these names may be different in yours.
In this lecture, we will try to use names
that help us easily identify the certificate files.
Another server in the cluster is the ETCD server.
The ETCD server stores all information about the cluster,
so it requires a pair of certificate and key for itself.
We will call it etcdserver.crt and etcdserver.key.
The other server component in the cluster is on the worker nodes.
They are the Kubelet services.
They also expose an HTTPS API endpoint that the Kube-api server talks to
to interact with worker nodes.
Again, that requires a certificate and key pair.
We call it kubelet.cert and kubelet.key.
Those are really the server components in the Kubernetes cluster.
Let's now look at the client components.
Who are the clients who access these services?
The clients who access the Kube-api servers
are us, the administrators,
through Kube control or REST API.
The admin user requires a certificate and key pair
to authenticate to the Kube-api Server.
We will call it admin.crt and admin.key.
The scheduler talks to the Kube-api Server
to look for pods that require scheduling
and then get the API server to schedule the pods
on the right worker notes.
The scheduler is a client that accesses the Kube-api Server.
As far as the Kube-api Server is concerned,
the scheduler is just another client like the admin user.
The scheduler needs to validate its identity
using a client TLS certificate.
It needs its own pair of certificate and keys,
we will call it scheduler.crt and scheduler.key.
The kube-controller-manager is another client
that accesses the kube-api server,
so it also requires a certificate for authentication to the kube-api server
so we create a certificate pair for it.
The last client component is the kube-proxy.
The kube-proxy requires a client certificate
to authenticate to the kube-api server,
and so it requires its own pair of certificate and keys.
We will call them kube-proxy.crt and kube-proxy.key.
The servers communicate amongst them as well.
For example, the kube-api server communicates with the etcd server.
In fact, of all the components,
the kube-api server is the only server that talks to the etcd server.
As far as the etcd server is concerned,
the kube-api server is a client, so it needs to authenticate
the kube-api server can use the same keys
that it used earlier for serving its own API service,
the apiserver.crt and the apiserver.key files.
Or you can generate a new pair of certificates
specifically for the kube-api server to authenticate to the etcd server.
The kube-api server also talks to the kubelet server
on each of the individual nodes.
That's how it monitors the worker nodes.
For this, again, it can use the original certificates
or generate new ones specifically for this purpose.
That's too many certificates, let's try and group them.
There are a set of client certificates
mostly used by clients to connect to the kube-api server,
and there are a set of server side certificates
used by the kube-api server, etcd server, and kubelet
to authenticate their clients.
We will now see how to generate these certificates.
As we know already,
we need a certificate authority to sign all of these certificates.
Kubernetes requires you to have
at least one certificate authority for your cluster.
In fact, you can have more than one,
one for all the components in the cluster,
and another one specifically for etcd.
In that case,
the etcd servers certificates and the etcd servers client certificates,
which in this case is the apiserver client certificate
will be all signed by the etcd server CA.
For now, we will stick to just one CA for our cluster.
The CA as we know
has its own pair of certificate and key,
we will call it ca.crt and ca.key.
That should sum up all the certificates used in the cluster.