There are several implementations for user account authentication. This includes anything from client certificates, bearer tokens, and static files to OpenID connect tokens. You can choose more than one as authentication chains. Here, we'll demonstrate how client certificates work.

In Chapter 9, Continuous Delivery, and earlier in this chapter, we learned how to export certificates and tokens for service accounts. Now, let's learn how to do this for a user. Let's assume that we are still inside the chapter5 namespace, and we want to create a user for our new DevOps member, Linda, who will help us do the deployment for my-app:

1. First, we'll generate a private key via OpenSSL (https://www.openssl.org):

// generate a private key for Linda
# openssl genrsa -out linda.key 2048

2. Next, we'll create a certificate sign request (.csr) for Linda:

// making CN as your username
# openssl req -new -key linda.key -out linda.csr -subj "/CN=linda" 

3. Now, linda.key and linda.csr should be located in the current folder. To let the API server validate Linda's certificate, we'll need to find the cluster CA.

Let's assume we have ca.crt and ca.key under the current folder; by using these, we could generate a new CA for the user. By using the -days parameter, we can define the expired date:

// generate the cert for Linda, this cert is only valid for 30 days.
# openssl x509 -req -in linda.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out linda.crt -days 30
Signature ok
subject=/CN=linda
Getting CA Private Key

After we have cert signed by our cluster, we could set a user in the cluster, as follows:

# kubectl config set-credentials linda --client-certificate=linda.crt --client-key=linda.key
User "linda" set.

Remember the concept of context: this is the combination of cluster information, a user for authentication, and a namespace. Now, we'll set a context entry in kubeconfig. Remember to replace your cluster name, namespace, and user in the following example:

# kubectl config set-context devops-context --cluster=${K8S_CLUSTER} --namespace=chapter5 --user=linda
Context "devops-context" modified.

Now, Linda should have zero permission:

// test for getting a pod 
# kubectl --context=devops-context get pods
Error from server (Forbidden): User "linda" cannot list pods in the namespace "chapter5". (get pods)

Linda can now pass the authentication stage as Kubernetes knows she is Linda. However, to give Linda permission to do the deployment, we need to set up the policies in authorization modules.