Kubernetes - Authentication

We already know that when a request comes to the API server, there are multiple stages which are performed. Authentication , authorization and admission control plugins exist in the API server which does individual jobs. 

When the request first comes to the API server, it creates a TLS connection by validating the client certificate with the certificate authority in the API server. The Certificate authority in the API server or master node exists in the /etc/kubernetes location. The client certificate generally exists in the ~/.kube/config location or /etc/kubernetes location. After the handshake is success, authentication comes into picture. The authentication modules in the API server are chained which means we can use more than 1. The auth check is carried out by all authentication modules until succeeded. If not , “HTTP 401 Unauthorized” error is thrown. 

The next is the authorization which is also a chained and throws “HTTP 403 Forbidden response” if all authorization modules fail. 

The final one is the admission control. Admission Control is a set of configurable plugins which determine if the request is admitted or denied. It also make sure that the request that came to API server are set with all values. It sets some default values if missing. 

In this page we will see how we can create a user and see how we can make that user to use the cluster. How we can authenticate the user in kubernetes.  

Lets create a private key for the user demouser using the openssl, 

[root@ip-172-31-12-239 ~]# openssl genrsa -out demouser.key 2048 

Generating RSA private key, 2048 bit long modulus 

.........+++ 

................................................................+++ 

e is 65537 (0x10001) 

[root@ip-172-31-12-239 ~]# # ll 

-rw-r--r--. 1 root root 1679 Nov 14 09:04 demouser.key 

Lets create a certificate sign request (.csr ) for demouser as below, 

[root@ip-172-31-12-239 ~]# openssl req -new -key demouser.key -out demouser.csr -subj "/CN=demouser" 

[root@ip-172-31-12-239 ~]# ll 

-rw-r--r--. 1 root root  891 Nov 14 09:13 demouser.csr 

-rw-r--r--. 1 root root 1679 Nov 14 09:12 demouser.key 

For approving the sign request, we need to locate the Certificate authority for our kubernetes cluster. The certificate authority will be available in the /etc/kubernetes/pki location.go to this location and run the openssl command as below, 

[root@ip-172-31-12-239 pki]# openssl x509 -req -in /root/demouser.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out /root/demouser.crt -days 30 

Signature ok 

subject=/CN=demouser 

Getting CA Private Key 

Now that the certificate is signed, we need to set the user with credentials using the certicates we created, 

[root@ip-172-31-12-239 ~]# kubectl config set-credentials demouser --client-certificate=demouser.crt --client-key=demouser.key 

User "demouser" set. 

Once the user is set with credentials, we need to set the context for that user. We all know that context is a combination of user, namespace and cluster. Set the context using, 

[root@ip-172-31-12-239 ~]# kubectl config set-context project1 --cluster=kubernetes --namespace=project1 --user=demouser 

Context "project1" modified. 

Now once the user is set, lets list the pods in the context project1 as below, 

[root@ip-172-31-12-239 ~]# kubectl --context=project1 get pods 

Error from server (Forbidden): pods is forbidden: User "demouser" cannot list resource "pods" in API group "" in the namespace "project1" 

Now if you see the above output , we can see that the user demouser is authenticated but could not get the list of pods as demouser has no permissions. Hence the forbidden error.