Creating Users to Access the Cluster

Understanding the scenario#

The word about Kubernetes’ awesomeness is spreading in your company. People are becoming curious and would like to try it out.

Since you are the Kubernetes guru, it came as no surprise that you received a call from John Doe. He wants to “play” with Kubernetes, but he does not have time to set up his own cluster. Since he knows that you already have a cluster up and running, he’d appreciate it if you would let him use yours.

Since you have no intention of giving John your certificates, you decide to let him authenticate with his user.

Installing openSSL#

You will have to create certificates for him, so the first step you’ll need to do is to verify that OpenSSL is installed.

It shouldn’t matter which version of OpenSSL is installed. We output the version only to verify that the software is working.

If the output is something like command not found: openssl, you will have to install the binaries.

Creating a user#

The first thing we’ll do is to create a private key for John. We’ll assume that John Doe’s username is jdoe.

We created the directory keys and generated a private key jdoe.key.

Next, we’ll use the private key to generate a certificate.

Creating final certificate#

We created the certificate jdoe.csr with a specific subject that will help us identify John. CN is the username and O represents the organization he belongs. John is a developer, so devs should do.

For the final certificate, we’ll need the cluster’s certificate authority (CA). It will be responsible for approving the request and for generating the necessary certificate John will use to access the cluster.

Since we used k3d, the authority is already produced for us as part of the cluster creation. It should be in the /usercode/certs directory as per the volume binding.

Let’s confirm it’s there.

The output is as follows.

Now we can generate the final certificate by approving the certificate sign request jdoe.csr.

Since we feel generous, we made the certificate jdoe.crt valid for a whole year (365 days).

To simplify the process, we’ll copy the cluster’s certificate authority to the keys directory.

Let’s check what we generated.

The output is as follows.

John does not need the jdoe.csr file. We used it only to generate the final certificate jdoe.crt. He will need all the other files though.

Getting the server address#

Apart from the keys, John will need to know the address of the cluster. At the beginning of the chapter, we already created the jsonpath that retrieves the server so that part should be easy.

The output is as follows. Note that the IP may differ.

Equipped with:

• The new certificate (jdoe.crt)
• The key (jdoe.key)
• The cluster authority (ca.crt)
• The address of the server,

John can configure his kubectl installation.

Try it yourself#

A list of all the commands used in the lesson is given below.

Troubleshooting Tips for minikube#

While working with minikube locally, we can access the certificate-authority in the following directory:

ls -1 ~/.minikube/ca.*

Minikube’s directory might be somewhere else, so replace the path accordingly while accessing the certificates from keys directory.