Certificates API

Certificates API

In this tutorial, we are going to discuss on 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 discussed 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.

A 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 the 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?

Certificate Authority (CA)

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 very 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 Certificate Signing Request 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.

How it is done?

A user first creates a key. Then generates a certificate signing request 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 Kubernetes 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.

apiVersion: certificates.k8s.io/v1 
kind: CertificateSigningRequest 
metadata:   
   name: ashok 
spec:
   groups:
   - system:authenticated
   usages:
   - digital signature
   - key encipherment
   - server auth
   request: LS0tLS1CRUdkghwIloftPdwdfdJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZJTim0wMUFSMkNJVXBGd2ZzSj=

Once the object is created, all certificate signing requests can be seen by administrators by running the following command

$ kubectl get csr
NAME           AGE     REQUESTOR                    CONDITION
ashok          14m     contact@sh121.global.temp.domains    PENDING

Identify the new request and approve the request by running the following command

$ kubectl certificate approve ashok
ashok approved!

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.

$ kubectl certificate approve ashok -o yaml

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.