Authentication
In this tutorial, we are going to discuss about authentication in a Kubernetes cluster.
As we have discussed already the Kubernetes cluster consists of multiple nodes physical/virtual and various components that work together.
We have users like,
- Administrators that access the cluster to perform administrative tasks
- Developers that access to cluster to test or deploy applications
- End users who access the applications deployed on the cluster
- Third party applications accessing the cluster for integration purposes.
Throughout this tutorial we will discuss how to secure our Kubernetes cluster by securing the communication between internal components and securing management access to the cluster through authentication and authorization mechanisms.
In this tutorial our focus is on securing access to the Kubernetes cluster with authentication mechanisms.
So we discussed about the different users that may be accessing the cluster security of end users who access the applications deployed on the cluster is managed by the applications themselves internally.
So we will take them out of our discussion. Our focus is on users access to the Kubernetes cluster for administrative purposes.
Accounts
So we are left with 2 types of users. Humans, such as the Administrators and Developers and Robots such as other processes/services or applications that requires access to the cluster.
Kubernetes does not manage user accounts natively it relies on an external source like a file with user details or certificates or a third party identity service like LDAP to manage these users.
And so you cannot create users in a Kubernetes cluster or view the list of users.
However in case of Service Accounts Kubernetes can manage them. You can create and manage service accounts using the Kubernetes API.
We will discuss and practice more about service accounts in further tutorials. For this section we will focus on users in Kubernetes.
All user access is managed by the API server. Weather you are accessing the cluster through kubectl tool or the API directly, all of these requests go through the Kube API Server.
The Kube API Server authenticates the requests before processing it. So how does the Kube API Server authenticate?
Authentication mechanisms
There are different authentication mechanisms that can be configured.
You can have a list of username and passwords in a static password file, or usernames and tokens in a static token file or you can authenticate using certificates.
And another option is to connect to third party authentication protocols like LDAP, Kerberos etc. We will discuss at some of these in upcoming tutorials.
Let’s start with static password and token files as it is the easiest to understand.
Let’s start with the simplest form of authentication. You can create a list of users and their passwords in a csv file and use that as the source for user information.
The file has 3 columns password, user name and user id.
ashok123,ashok,u0001 ramu@123,ramu,u0002 lakshman@321,lakshman,u0003 seetha@12345,seetha,u0004 hanuma@123,hanuma,u0005
We then pass the file name as an option to the Kube API Server. (kube-apiserver.service file)
--basic-auth-file=user-details.csv
You must then restart the Kube API Server for these options to take effect.
If you setup your cluster using the kubeadm tool, then you must modify the Kube API Server POD definition file.
Kubeadm tool will automatically restart the Kube API Server once you update the file.
To authenticate using the basic credentials while accessing the API server specify the user and password in a curl command like this.
$ curl -v -k https://10.0.1.2:6443/api/v1/pods -u "ashok:ashok123"
In the csv file with the user details that we saw we can optionally have a fourth column with the group details to assign users to specific groups.
ashok123,ashok,u0001,group1 ramu@123,ramu,u0002,group1 lakshman@321,lakshman,u0003,group2 seetha@12345,seetha,u0004,group2 hanuma@123,hanuma,u0005,group2
Similarly instead of a static password file, You can have a static token file here instead of password you specify a token pass the token file as an option token-auth-file to the Kube API Server.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9,ashok,u0001,group1 eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6M,ramu,u0002,group1 6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0N,lakshman,u0003,group2 b73C75osbmwwshQNRC7frWUYrqaTjTpza2y4,seetha,u0004,group2 VzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxND,hanuma,u0005,group2
token-auth-file=user-details.csv
While authenticating specify the token as an Authorization bearer token to your requests like this.
$ curl -v -k https://10.0.1.2:6443/api/v1/pods --header "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9"
Note
- This authentication mechanism that stores user names, passwords and tokens in clear text in a static file is not a recommended approach as it is insecure. But I thought this was the easiest way to understand the basics of authentication in Kubernetes.
- If you were trying this out in a kubeadm setup you must also consider volume mounts to pass in the auth file.