Hello and welcome to this lecture in this lecture
We look at how to manage certificates and what the certificate API is in kubernetes.
So what have we done so far.
I as an administrator of the cluster in the process of setting up the whole cluster have set up a CA
server and bunch of certificates for various components.
We then started the services using the right certificates and it's all up and working and the only administrator
and user of the cluster and I have my own admin certificate and key the new admin comes into my team.
She needs access to the cluster.
We need to get her a pair of certificate and key pair for her to access the cluster.
She creates her own private key generates a certificate signing request and sends it to me since I'm
the only admin.
I then takes the certificate signing request to my CA server, gets it signed by the CA using
the CA servers private key and root certificate, thereby generating a certificate and then sends
the certificate back to her.
She now has her own valid pair of certificate and key that she can use to access to cluster the certificates
have a validated period it ends after a period of time.
Every time it expires we follow the same process of generating a new CSR and getting it signed by the
CA.
So we keep rotating the certificate files. So we keep talking about the CA server.
What is the CA serve and where is it located in the Kubernetes setup? The CA
It is really just a pair of key and certificate files we have generated.
Whoever gains access to these pair of files, can sign any certificate for the kubernetes environment.
They can create as many users as they want but whatever privileges they want.
So these files need to be protected and stored in a safe environment say we place them on a server that
is fully secure.
Now that server becomes your CA server. The certificate key file is safely stored in that server and
only on that server every time you want to sign a certificate you can only do it by logging into that
server.
As of now we have the certificates placed on the kubernetes master node itself. So the master node
is also our CA server.
The kubeadm tool does the same thing.
It creates a CA pair of files and stores that on the master node itself.
So far we have been signing requests manually but as and when the users increase and your team grows
you need a better automated way to manage the certificates signing requests as well as to rotate certificates
when they expire.
Kubernetes has a built-in Certificates API that can do this for you. With the Certificates API, you now
send a CertificateSigningRequest directly to kubernetes through an API call. This time, when the administrator
receives a certificate signing request instead of logging onto the master node and signing the certificate
by himself.
he creates a Kubernetes API object called CertificateSigningRequest.
Once the object is created all certificates any requests can be seen by administrators of the cluster.
The request can be reviewed and approved easily using kubectl commands this certificate can then
be extracted and shared with the user.
Letâ€™s see how it is done. A user first creates a key. Then generates a certificate signing request using
using the key with her name in it. Then sends the request to the administrator. The administrator takes the key
and creates a certificatesigningrequest object.
The CertificateSigningRequest is created like any other kuberenetes object using a manifest
file with the usual fields. The kind is CerificateSingingRequest. Under the spec section, specify
the groups the user should be part of and list the usages of the account as a list of strings the request
field is where you specify the certificate signing request sent by the user but you don't specify it
as plain text instead it must be encoded using the base64 command then move the encoded text into the
request field and then submit the request once the object is created.
all certificate signing requests can be seen by administrators by running the kubectl get csr
command. Identify the new request and approve the request by running the kubectl certificate approve
command. Kubernetes signs the certificate using the CA key pairs and generates a certificate for the
user.
This certificate can then be extracted and shared with the user view the certificate by viewing it in
a YAML format. The generate certificate is part of the output. But as before it is in a base64 encoded
format to decode it.
Take the text and use the base 64 utilities decode option.
This gives the certificate in a plain text format.
This can then be shared with the end user.
Now that we have seen how it works let's see who does all of this for us.
If you look at the kubernetes control plane, you see the kube-api server, the scheduler, controller manager,
etcd server etc.
Which of these components is actually responsible for all the certificate related operations all the
certificate related operations are carried out by the controller manager.
If you look closely at the controller or manager you will see that it has controllers in it called as
csr-approving, csr-signing etc that are responsible for carrying out these specific tasks.
We know that if anyone has to sign certificates, they need the CA servers root certificate and private
key.
The controller manager service configuration has two options where you can specify this well that's
for this lecture.
Head over to the practice test and play around with the certificates API.
I will see you in the next lecture.